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: <3CD42CF7.874A8C49@yahoo.com> Date: Sat, 04 May 2002 14:48:23 -0400 From: Earnie Boyd X-Accept-Language: en MIME-Version: 1.0 To: Charles Wilson 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles Wilson wrote: > Earnie Boyd wrote: > > > I see it's time for me to chime in. We the cygwin-apps developers must > > insist that all X11 packages use --prefix=/usr/X11R6 because it's possible > > for an X11 package to be both Win32 and X11, E.G.: rxvt. And I the user > > could want to use either depending on the moode (spelling intentional) I'm > > in. > > 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. > 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? > > 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). > 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. > > 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. > > 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. > > 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? Earnie. P.S.: moode - The mode of operation depending on the mood of the person executing the process based upon the mode of the environment which itself is dependant of the mood of the person initializing the environment.