This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: new cygwin package: cgoban


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 ...).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]