Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm Sender: cygwin-apps-owner AT cygwin DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps AT cygwin DOT com Delivered-To: mailing list cygwin-apps AT cygwin DOT com Message-ID: <3CD440EF.9070405@ece.gatech.edu> Date: Sat, 04 May 2002 16:13:35 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Earnie Boyd CC: Earnie Boyd , Robert Collins Subject: Re: new cygwin package: cgoban References: <3CD3DD22 DOT 76BD5C0 AT yahoo DOT com> <3CD428C7 DOT 8000206 AT ece DOT gatech DOT edu> <3CD42CF7 DOT 874A8C49 AT yahoo DOT com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Earnie Boyd wrote: >> Bad example, Earnie. The current rxvt package is, itself, in a >> single binary, BOTH Win32 AND X11. It is fine right where it is >> (--prefix=/usr). > No, it's a good example. And you're correct the existing rxvt > package is fine right where it is. It's the one that uses the > Xsever displays that'll need to be in /usr/X11R6/bin. !!! Earnie, please do the following: start your Xserver. set DISPLAY=127.0.0.1:0.0 execute /usr/bin/rxvt.exe ---> Ta-da! it's an X application. **The current rxvt executable DOES/CAN use the Xserver displays if the DISPLAY= variable is set to something other than :0** Now, it doesn't *require* the X libraries -- the way the cygwin port is coded, it does a dlopen on either "libW11.dll" or "libX11.dll" depending on the DISPLAY variable. Nobody has made a big deal ofthe following: if you don't have X11 installed, but you set DISPLAY=127.0.0.1:0.0, then rxvt.exe will fail with a "failed to load libX11.dll" error. >> Now, if you want to distinguish between, say, and XEmacs that is >> built using native MS windowing only (which should go into >> --prefix=/usr) and an XEmacs built using X11 windowing (which, >> depending on how this discussion ends, MIGHT go into >> --prefix=/usr/X11R6), then that's a different issue. > Well, yes, it's the same principal. Or do you mean that rxvt as is > will execute on either X11 WM or Win32 WM? Yep. >> However, even in that case, I'm not sure I agree with you. Suppose there WERE two tentative "XEmacs" packages. Should a user be able to >>install both at the same time? >> > > Why not, it should be the users choice, depending on the moode (see > the P.S. for definition). I agree -- it was a rhetorical question, but one that led to the following.... (however, I notice that Mandrake, of late, doesn't allow users to install "normal X" XEmacs along with "gtk" XEmacs. They only provide the gtk version...but that's just an aside) >>Then he would be duplicating all 50Meg >>of the elisp code -- which is identical -- in /usr/share/xemacs/ and >>/usr/X11R6/share/xemacs/. The two packages would have to have different >>names -- XEmacs-MS- and XEmacs-X- ? Or should these two packages be >>coordinated -- XEmacs-MS- (which contains binary and libs), XEmacs-X >>(ditto), and a separate XEmacs-elisp (which both use, and installs the >>50M of elisp into --prefix=/usr.) But in that case, the XEmacs-X >>package isn't really "--prefix=/usr/X11R6" -- it's "--prefix=/usr >>--bindir=/usr/X11R6/bin --libdir=/usr/X11R6/lib". This is a messy issue. > Messy issue correct, but could be covered by varying startup scripts > and which path is listed first in the path list. I.E.: If I want to > default to X11 binaries I have a PATH similar to /usr/X11R6/bin:/bin > and if I want to default to Win32 binaries I have a PATH similar to > /bin:/usr/X11R6/bin. Yes, but you're not addressing my point: the "three package" solution to the "XEmacs problem" implies that XEmacs-X is NOT configured by a simple "--prefix=/usr/X11R6/". An I think you would agree that the "three package" solution makes a lot of sense, given the size of XEmacs-elisp... The larger point it this: you're really talking about two different architectures. Binaries on either "architecture" can share the same non-architecture-specific data. That's what /share is FOR according to the FHS. Therefore, the X binary and the MSnative binary SHOULD use the same /share directory (in the case of XEmacs, for the elisp) (*). But how can they do that if we blindly say "XEmacs-X must be --prefix=/usr/X11R6/"? (*) However, for arcane reasons lost in the mists of time, xemacs DOESN'T use /share for its package elisp, it puts it by default into lib/xemacs/xemacs-packages/; however, the principle of "shared stuff between architectures should go into /shared" still holds -- and still implies that --prefix=/usr for both X port and MSnativeWindowing port, so that $prefix/shared/ == $prefix/shared/. Xemacs is just a bad example. Actually, given that the XEmacs folks already provide a cygwin port -- which is not compatibile with the cygwin's package system -- I doubt there will ever be a "cygwin official" xemacs package. (I guess you'd call the current offering an "XEmacs official cygwin package") Also, there's nothing in your "moode" that prevents THIS from working; you don't need to muck with PATH: MOODE=X MOODE=MS /usr/bin/xemacs == shell script: ------ #!/bin/sh if [ "X$MOODE" == "XX" ] ; then exec xemacs-X $* else exec xemacs-MS $* fi ----- And then *everything* can live in --prefix=/usr. Or heck, just do what rxvt does: switch MOODE based on DISPLAY! -------------- #!/bin/sh if [ -z `echo $DISPLAY | sed -n '/^[[:digit:].]*$/p'` ] ; then exec xemacs-X $* else exec xemacs-MS $* fi ------------- >>Basically, what I am getting at is you are raising a whole nother can of >>worms: (1) programs that can exist in EITHER "native" or "X" forms. > Yes. >>That is a different issue than (2) programs which are simultaneously, >>within the same binary, BOTH "native" and "X" (e.g. your rxvt example) >>and it is a different issue than (3) programs that exist ONLY in "X" form. > Ok, so you are saying that the current rxvt package can execute in either mode, > wasn't aware of that. Yep. See above. >>Let's limit this discussion to group (3), okay? > No, we need to make the decision based on (1) and (3). I agree that (2) goes to > prefix=/usr. ! Well, at least we agree on SOMETHING. >>On group (1), anybody want to check how Red Hat separates/enables >>coexistence of packages that are either X or SVGAlib, and take that to a >>different thread? We already know that (group 3) almost all X programs >>(with very few exceptions) go into --prefix=/usr on RHL. > How does that matter? If I have a GUI application that I want either Win32 or > X11 depending on moode and it doesn't do it automagically? Because in X vs. MS, switching "moode" based on PATH is unnecessary. You can use the DISPLAY variable instead. For those FEW programs that will ever be in the (1) category, they can have separate names + a wrapper like the one above(*). Now, we're back to group (3) -- and again, I think these should live in --prefix=/usr, just like all the Linux distributions do. (note: originally I said I "kinda liked" the idea of using --prefix=/usr/X11R6 for X apps. After more thought, it doesn't seem right, and it's different from what most linux dists do, so I'd really rather --prefix=/usr for all [except XFree86 itself, of course]) --Chuck (*) counter argument: gtk+ on cygwin currently uses X. However, the code is THERE to use native MS windowing -- because there is a native MS port (on a separate CVS branch). It might be possible, some time in the future, to have TWO different "gtk+" builds on cygwin: and X one and an MS one (it is not CURRENTLY possible to do that). But, in that eventuality, you could then have a whole SLEW of cygwin ports of gtk+-based programs that could be compile as "X" apps or as "native MS windowing" apps -- depending on which version of the gtk+ libs they were linked against. But should we borrow trouble against something that may never happen? (Tor Lilqvist, maintainer of the windows port of gtk+, doesn't seem too enthusiastic about refactoring to separate his native-windowing stuff from his msvcrt-not-glibc-runtime stuff; it's all #if _MSWIN ...).