Re: new cygwin package: cgoban
Charles Wilson wrote: (*) 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 ...). Ah, now the point at which I was trying to drive home at. Yes, IMO, we should borrow trouble as that trouble is most likely to happen. It's much like the MinGW libraries where the headers and libraries need to be segregated, so will these apps. Earnie.
Re: new cygwin package: cgoban
Earnie Boyd wrote: (*) 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 ...). Ah, now the point at which I was trying to drive home at. Yes, IMO, we should borrow trouble as that trouble is most likely to happen. It's much like the MinGW libraries where the headers and libraries need to be segregated, so will these apps. Again, this is more of a name vs. a path issue -- especially when it comes to the gtk DLLs, for instance. SO WHAT if a cygwin libgtk+1.3.0.dll that uses the X libs lives in /usr/X11R6/bin and another cygwin libgtk+1.3.0.dll that uses native MS windowsing lives in /usr/bin -- switching PATH around to prefer one over the other is STILL a recipe for trouble. Not to mention conflicts with the truly natiove libgtk+1.3.0.dll that lives in you GIMP installation folder! Seems like The Right Thing is to have cyggtk+X-1.3.0.dll and cyggtk+MS-1.3.0.dll. And then it doesn't matter where the DLLs live, and you needn't muck with PATH at all. But then, you're talking about segregating the import libraries and header files (and possibly configuration files) -- and THAT takes MORE than just mucking with PATH. Whaddaya want to do, add new switches to cygwin's gcc: -muse-native-windowing-libraries and -muse-X-windowing-libraries to switch the default -I and -L paths, like -mno-cygwin does? My point: there are just too damn many issues to armchair this one. We are NOT going to get it right until we actually HAVE cygwin packages that are available as either X or MS windowing, but not both. Right now, we have NONE. ALL we have are X-only (many), MS-only (*), or BOTH X- and MS- in the same binary (**). The theoretical possibility of maybe perhaps having libraries or binaries that are available in X- or MS- windowing versions (excluding both in same executable) is NOT enough to solve this one, IMO. Give me a REAL example where it ACTUALLY matters, right now. Otherwise, let's just drop this thread. We've changed packaging standards before. I've had to repackage my stuff at least twice (lib*.dll - cyg*.dll, FOO_STATIC - autoimport) due to merely packaging changes. If we have to rearrange things later, that's what maintainers DO. (*) actually, we may not have ANY of these -- except setup.exe itself, but that is not a cygwin-linked program anyway... (**) just one, at present - rxvt. --Chuck
RE: new cygwin package: cgoban
Get a new setup.exe from http://www.cygwin.com/setup.exe. Rob -Original Message- From: Teun Burgers [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 04, 2002 5:46 PM To: [EMAIL PROTECTED] Subject: Re: new cygwin package: cgoban I see the original message has led to quite some discussion and even a decree. What is the status on the upload? My setup.exe seems to crash on an increasing number of mirrors right after download of setup.ini. This is the message: SETUP heeft een algemene beschermingsfout veroorzaakt in module USER.EXE op 0004:5ff0. (dutch for general protecting fault). Charles Wilson wrote: Similarly, I don't like the restriction that all 'X'-based packages go under XFree86/ on sourceware. We don't put inetutils underneath ncurses/. We don't put openssh under openssl/. And: Further, if one accepts that there should be one tree for all X **clients**, you've never stated WHY that single tree must be the same one used by the XFree86 packages. They aren't PART of XFree86. They just USE XFree86. I couldn't agree more. Putting them under XFree86 strongly suggests that the package would be part of XFree86, and that is not the case. Teun Burgers
Re: new cygwin package: cgoban
Robert Collins wrote: -Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 04, 2002 5:04 AM Volker Zell agreed. Nobody else responded. I kinda like it, but FHS has moved away from that; now on Red Hat systems it appears that ONLY those programs specifically part of XFree86 are included there -- or programs whose purpose is to manipulate XFree86 itself (like third-party Xconfigurators and such). I'm agnostic on this one, I don't use X enough to really care. However, Earnie has pointed out that extra path elements have a lamentable performance impact, so perhaps we should be avoiding that? 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. Earnie.
Re: new cygwin package: cgoban
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). 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. 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? 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. 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. 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. Let's limit this discussion to group (3), okay? 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. --Chuck
Re: new cygwin package: cgoban
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.
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
Re: new cygwin package: cgoban
On Fri, May 03, 2002 at 11:46:33AM +0200, Corinna Vinschen wrote: On Tue, Apr 30, 2002 at 07:49:49PM +0200, Teun Burgers wrote: Hello, I've uploaded binary and source packages of cgoban, homepage kgs.kiseido.com/~wms/comp/cgoban/ These are the URL's of binary and source tarballs: http://home.quicknet.nl/qn/prive/ar.burgers/cgoban-1.9.12-1.tar.bz2 http://home.quicknet.nl/qn/prive/ar.burgers/cgoban-1.9.12-1-src.tar.bz2 The tarballs were prepared with generic-build-script.sh. Here is the setup.hint: category: Games Xfree86 requires: Xfree86-base gnugo sdesc:X11 Client to IGS and NNGS go servers, SGF editor, GUI for Gnu Go ldesc:X11 Client to IGS and NNGS go servers, SGF editor, GUI for Gnu Go cgoban is an X11 program related to the game of go. With cgoban you can connect to the IGS and NNGS go servers to play online. You can create and edit SGF (Smart Game Format) files. You can play on your computer against Gnu Go or any other program that communicates throught the Go Modem Protocol (GMP). I hope I got it right! Packaging looks good. I've uploaded the package to cygwin.com. Please prepare to announce according to http://cygwin.com/setup.html#submitting Section 9 in a few hours. This wasn't entirely correct. The package name for XFree86-base was Xfree86-base. Also, I would prefer if packages that relied on X were put in the XFree86 hierarchy. cgf
Re: new cygwin package: cgoban
Christopher Faylor wrote: This wasn't entirely correct. The package name for XFree86-base was Xfree86-base. Also, I would prefer if packages that relied on X were put in the XFree86 hierarchy. Also, Trevor Forbes suggested that X-dependent programs should be compiled using --prefix=/usr/X11R6/ (and --sysconfdir=/etc/X11/ ?), as is common on unix systems... Volker Zell agreed. Nobody else responded. I kinda like it, but FHS has moved away from that; now on Red Hat systems it appears that ONLY those programs specifically part of XFree86 are included there -- or programs whose purpose is to manipulate XFree86 itself (like third-party Xconfigurators and such). Similarly, I don't like the restriction that all 'X'-based packages go under XFree86/ on sourceware. We don't put inetutils underneath ncurses/. We don't put openssh under openssl/. If you really want to segregate X apps, create another tree: Xopt/ or something (and give Harold official control of that tree, too). I think XFree86/ should be reserved for the XFree86 distribution itself. I'd like to see a definitive answer to both of these questions, tho, before we get too many X programs in the distribution... 1) --prefix=/usr/X11R6/ 2) packages uploaded under XFree86/ --Chuck
RE: new cygwin package: cgoban
-Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 04, 2002 1:33 AM This wasn't entirely correct. The package name for XFree86-base was Xfree86-base. Setup is case-insensitive, so while there is a visual discrepancy, setup will be happy. Rob
RE: new cygwin package: cgoban
-Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 04, 2002 5:04 AM Volker Zell agreed. Nobody else responded. I kinda like it, but FHS has moved away from that; now on Red Hat systems it appears that ONLY those programs specifically part of XFree86 are included there -- or programs whose purpose is to manipulate XFree86 itself (like third-party Xconfigurators and such). I'm agnostic on this one, I don't use X enough to really care. However, Earnie has pointed out that extra path elements have a lamentable performance impact, so perhaps we should be avoiding that? Similarly, I don't like the restriction that all 'X'-based packages go under XFree86/ on sourceware. We don't put inetutils underneath ncurses/. We don't put openssh under openssl/. I'm 100% with you here. If it's a package, then it goes under release. If we want a completely separate tree, create a new location and a new setup.ini, and then that becomes the cygwin-xfree lists domain, and they can have whatever policy they want. Whilst it's in the main setup.ini, they need to follow the policies that this list has hammered out - with much pain. If you really want to segregate X apps, create another tree: Xopt/ or something (and give Harold official control of that tree, too). I think XFree86/ should be reserved for the XFree86 distribution itself. Agreed. I'd like to see a definitive answer to both of these questions, tho, before we get too many X programs in the distribution... 1) --prefix=/usr/X11R6/ In short: I don't really care, but am not in favour of. 2) packages uploaded under XFree86/ Really don't like this. Rob
Re: new cygwin package: cgoban
Be sure to read the p.s. ... Christopher Faylor wrote: On Fri, May 03, 2002 at 03:04:04PM -0400, Charles Wilson wrote: Similarly, I don't like the restriction that all 'X'-based packages go under XFree86/ on sourceware. We don't put inetutils underneath ncurses/. We don't put openssh under openssl/. I wasn't really asking for debate. You can feel free not to like it but that is the way I would like to see things organized. Sorry, Chris, but it's my turn to get pissy. Why? You have never stated, not one time that I've seen, WHY you want to put all X-related stuff under a single tree. As long as they are under release/, they're still going to show up in setup no matter where they are located, so setup's behavior can't have anything to do with it. If it's a cleanliness issue (don't clutter the main release/ dir with all that X junk) -- fine, SAY that. At least it's a reason -- and a slightly better one than because I said so. And I've already heard the one about because we're mean. Further, if one accepts that there should be one tree for all X **clients**, you've never stated WHY that single tree must be the same one used by the XFree86 packages. They aren't PART of XFree86. They just USE XFree86. It's not that I merely 'don't like it' -- I think this second part is irredeemably dumb. WHAT am I missing? Please tell me; you normally don't make executive assertions without a reason, you don't normally do dumb things; yet you seem to be doing so now...which makes me think I am somehow missing the obvious reasoning behind your assertion. This just makes zero sense to me: release/package/ release/package/ release/XFree86/ release/XFree86/xfree86-base/ release/XFree86/xfree86-fonts/ release/XFree86/xfree86-.../ release/XFree86/i-happen-to-use-x-package1/ release/XFree86/i-happen-to-use-x-package2/ release/XFree86/i-happen-to-use-x-package3/ release/XFree86/i-happen-to-use-x-package4/ release/XFree86/i-happen-to-use-x-package5/ release/XFree86/i-happen-to-use-x-package6/ release/XFree86/i-happen-to-use-x-package7/ release/XFree86/i-happen-to-use-x-package8/ This makes (some) sense, from a 'keep-release/-clutter-to-a-minimum' perspective ... release/package/ release/package/ release/XFree86/ release/XFree86/xfree86-base/ release/XFree86/xfree86-fonts/ release/XFree86/xfree86-.../ release/Xclients/i-happen-to-use-x-package1/ release/Xclients/i-happen-to-use-x-package2/ release/Xclients/i-happen-to-use-x-package3/ release/Xclients/i-happen-to-use-x-package4/ release/Xclients/i-happen-to-use-x-package5/ release/Xclients/i-happen-to-use-x-package6/ release/Xclients/i-happen-to-use-x-package7/ release/Xclients/i-happen-to-use-x-package8/ --Chuck P.S. wait a minute; I thought of something. Is this a prelude to Any questions about packages that appear under /XFree86/ should be directed to the cygwin-xfree list? And you're afraid that splitting out the Xclients -- either into /release/ or into /release/Xclients/ -- would cloud that issue?
