RE: setup changes to build standalone
-Original Message- From: Gary R. Van Sickle [mailto:[EMAIL PROTECTED]] Sent: Friday, April 26, 2002 2:25 PM On a separate but related topic, I'd like to automakeise (is that a word) setup - if there are no objections from the other contributors. No, on the contrary I think that's a great idea. Raw Makefile.in's scare the hell out of me. ;-) Heh. The main things I get from automake is a) make dist. I _love_ this so much it ain't funny. b) all the 'stock' rules - so that things like make clean _always_ hit all subdirs etc etc. c) consistent VPATH support. d) multicompiler dependencies (not that I personally use it much, I'm gcc most everywhere) e) non-recursive makefiles of a reasonable size. Makefile.in's aren't good or bad in raw form IMO. Rob
Re: setup changes to build standalone
Robert Collins [EMAIL PROTECTED] writes: Heh. The main things I get from automake is a) make dist. I _love_ this so much it ain't funny. If you're willing to depend on gnu make features, make dist is no rocket science. Because of the horrors of automake, we've implemented a sane set of make rules, mainly for LilyPond, that has all these features and allows e) non-recursive makefiles of a reasonable size. a make file for a library or executable typically about 10 lines long. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
RE: setup changes to build standalone
-Original Message- From: Jan Nieuwenhuizen [mailto:[EMAIL PROTECTED]] Sent: Friday, April 26, 2002 6:42 PM I'll have a look at some point. I actually find automake much less horrible that doing everything by hand. Anyway, this is off-topic here - unless you are objecting to setup being automakified? No, it's rather off-topic, sorry. No problem, just ensuring we didn't end up in a -long- discussion about automakes +'s and -'s. Cheers, Rob
Re: setup changes to build standalone
Charles Wilson wrote:
Robert Collins wrote:
Yes. I even documented all this some time back on
http://www.cygwin.com/ml/cygwin-apps/2001-11/msg00634.html, but
predicatably enough, no patches where forthcoming. Probably due to the
complete lack of a prebuilt bz2lib for mingw (that my cursory searches
have looked for).
https://sourceforge.net/projects/mingwrep/
I don't know if the maintainers of this site are still maintaining it.
Paul Sokolovsky isn't active any longer and Stefan Jahn isn't a MinGW
developer. This is one of those projects that I wish weren't. OTOH,
https//sourceforge.net/projects/mingw/ would be willing to upload any
MinGW package if it followed the --prefix=/mingw --host=mingw32
packaging rules (which unfortunately aren't documented except in the
mingw-dvlpr archives) and that person was willing to maintain the
pacakge (would need a SF account and be listed as a MinGW developer).
I wonder if we need a mingw-libs package.
Yes, please, please, yes. I would really really love it if some of the
common libs (zlib, bz2lib, stdc++) where available in a setup.exe
installable pacakge.
Yes, I like this too -- but I'm nervous about it growing ridiculously
large. What if (eventually) setup.ini turns into XML? Do we put a
mingw build of libxml into 'mingw-libs'? How far does this go?
(visions of full{mingw}.exe)
OTOH, we've already discussed (and discarded, thank g-d) the idea of
(for instance) the zlib maintainer providing both a
cygwin-setup-installable zlib package (/usr/bin/cygz.dll,
/usr/lib/libz.[dll|a]) and a cygwin-setup-installable mingw-zlib package
(/usr/bin/mgwz.dll, /usr/lib/mingw/libz.[dll|a]). Ditto bzip2, libxml,
... we are not a mingw-porting factory.
This is good. IMO, there should be no binaries not dependent on
cygwin1.dll in the /bin a.k.a. /usr/bin and that the /bin and /usr/bin
directories be marked as --cygwin-executable. One reason for doing this
is that it speeds the execution process for spawning by avoiding win32
translations.
2) The above won't work in a cross build environment. You could say
CC='i686-pc-cygwin-gcc -mno-cygwin'..., I guess.
for cross compiles:
../setup/configure --host=i686-pc-mingw32 --build-i686-pc-linux
should do it (assuming a mingw32 cross compiler is present), or a
combination using the CC string you have above with the mingw host will
work too.
whatever happened to the idea of an official cygwin package, that
contained a true cygwin-host, mingw-target cross compiler? Didn't
somebody or other volunteer to provide that?
Oh, I thought about it sometime ago, I've been busy with MSYS and have
decided against my maintaining another package. Perhaps when Danny gets
3.1 up he can provide a Cygwin hosted Mingw32 targeted set of binaries.
I also remember a discussion on one of Cygwin's lists about using
scripts and symlinks to emulate this and may be the smartest way to go
about providing cross build emulation.
(Granted, we still need 'cygwin-gcc -mno-cygwin' for the self-hosting
feature of cygwin1.dll, but there's no real need to *require* cygwin-gcc
-mno-cygwin for setup.exe, now that setup has been moved out of the
winsup tree)
Well, if you had a mingw32-gcc (cygwin hosted, mingw32 targeted) then
you could use that instead of `gcc -mno-cygwin'.
anything that is non-simple. I haven't looked at it in a
while, though, so maybe things have changed.
It really depends on what you want to do. Some stuff it does
spectalularly well, some things it has trouble with. With the 'cross
compiling but not' approach, it would almost certainly have some trouble
:}.
see above, true cross compiler...
Or even the simulated with script and symlink one.
Earnie.
Re: setup changes to build standalone
Robert Collins wrote: d) a --with-cygwin-headers=/path/to/headers and in mount.cc pickup the needed headers. With a default of $(prefix)/include. Earnie.
RE: setup changes to build standalone
-Original Message- From: Earnie Boyd [mailto:[EMAIL PROTECTED]] Sent: Friday, April 26, 2002 10:34 PM To: Robert Collins Cc: Cygwin-Apps Subject: Re: setup changes to build standalone Robert Collins wrote: d) a --with-cygwin-headers=/path/to/headers and in mount.cc pickup the needed headers. With a default of $(prefix)/include. Exactly. Rob
Re: setup changes to build standalone
On Fri, Apr 26, 2002 at 01:03:05PM +1000, Robert Collins wrote: To build setup we need: a mingw bz2lib a mingw zlib w32api in the future (soon I hope): a mingw libstdc++ (and any dependencies it has). So, I've made a copy of bz2lib from src/winsup/bz2lib to set/bz2lib, and adjusted accordingly. Ack. Duplication. Duplication bad. Here was a good reason not to move cinstall. Sigh. I can't think of any way around this, though. Even if we say You must have a mingw version of libbz2.a available that will screw up my need for this library in winsup. I wonder if we need a mingw-libs package. A second issue is that I cannot get configure to play nice in the new location without updating to 2.5x. That doesn't concern me, does it concern anyone else? Nope. The configure line to prepare a website version of setup will be: ../setup/configure' --host=i686-pc-mingw32 --build=i686-pc-cygwin 'CC=gcc -mno-cygwin' 'CXX=g++ -mno-cygwin'. It should configure and build a cygwin1.dll linked version quite happily if the --host parameter is left off. That may also be useful for test builds and the like, and also for building command line mirroring tools etc etc. 1) Why the --host=? So that you'll be able to use a mingw version of everything? 2) The above won't work in a cross build environment. You could say CC='i686-pc-cygwin-gcc -mno-cygwin'..., I guess. I'll post a patch (probably up on sources.redhat.com/cygwin-apps/setup) when I've got everything ready. (It's gonna be big (at least the size of bz2lib :}) or I'd just drop it here). Then if a couple of folk have success with it, I'll check it in. Any comments, peanuts, etc? I think you should just check it in and tweak things in cvs rather than post a patch. It's not going to impact anyone but a tiny handful of people if you use cvs but it will impact a much larger audience if you send out patches. On a separate but related topic, I'd like to automakeise (is that a word) setup - if there are no objections from the other contributors. I'll do this as a separate commit, that is if noone has serious issues with it. I actually started doing this when the cinstall directory was first introduced then realized, as I always do, that I hate automake. For me, it requires too much pain to get it to do anything that is non-simple. I haven't looked at it in a while, though, so maybe things have changed. Nevertheless, I have no objections to this. cgf
RE: setup changes to build standalone
-Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Friday, April 26, 2002 1:19 PM So, I've made a copy of bz2lib from src/winsup/bz2lib to set/bz2lib, and adjusted accordingly. Ack. Duplication. Duplication bad. Yup. Here was a good reason not to move cinstall. Sigh. Yes. I even documented all this some time back on http://www.cygwin.com/ml/cygwin-apps/2001-11/msg00634.html, but predicatably enough, no patches where forthcoming. Probably due to the complete lack of a prebuilt bz2lib for mingw (that my cursory searches have looked for). I can't think of any way around this, though. Even if we say You must have a mingw version of libbz2.a available that will screw up my need for this library in winsup. I wonder if we need a mingw-libs package. Yes, please, please, yes. I would really really love it if some of the common libs (zlib, bz2lib, stdc++) where available in a setup.exe installable pacakge. 1) Why the --host=? So that you'll be able to use a mingw version of everything? Yes. It gets rid of the need for mingw_foo in the make files, and makes it explicit that we are cross compiling. 2) The above won't work in a cross build environment. You could say CC='i686-pc-cygwin-gcc -mno-cygwin'..., I guess. for cross compiles: ../setup/configure --host=i686-pc-mingw32 --build-i686-pc-linux should do it (assuming a mingw32 cross compiler is present), or a combination using the CC string you have above with the mingw host will work too. I think you should just check it in and tweak things in cvs rather than post a patch. It's not going to impact anyone but a tiny handful of people if you use cvs but it will impact a much larger audience if you send out patches. Ok, will do. anything that is non-simple. I haven't looked at it in a while, though, so maybe things have changed. It really depends on what you want to do. Some stuff it does spectalularly well, some things it has trouble with. With the 'cross compiling but not' approach, it would almost certainly have some trouble :}. Rob
Re: setup changes to build standalone
On Fri, Apr 26, 2002 at 01:44:32PM +1000, Robert Collins wrote: 2) The above won't work in a cross build environment. You could say CC='i686-pc-cygwin-gcc -mno-cygwin'..., I guess. for cross compiles: ../setup/configure --host=i686-pc-mingw32 --build-i686-pc-linux should do it (assuming a mingw32 cross compiler is present), or a combination using the CC string you have above with the mingw host will work too. Assuming you have a mingw cross compiler is what I was trying to avoid. For this purpose a 'gcc -mno-cygwin' compiler should work fine. I think the use of CC='i686-pc-cygwin-gcc -mno-cygwin' should work everywhere though. cgf
Re: setup changes to build standalone
Robert Collins wrote:
Yes. I even documented all this some time back on
http://www.cygwin.com/ml/cygwin-apps/2001-11/msg00634.html, but
predicatably enough, no patches where forthcoming. Probably due to the
complete lack of a prebuilt bz2lib for mingw (that my cursory searches
have looked for).
https://sourceforge.net/projects/mingwrep/
I wonder if we need a mingw-libs package.
Yes, please, please, yes. I would really really love it if some of the
common libs (zlib, bz2lib, stdc++) where available in a setup.exe
installable pacakge.
Yes, I like this too -- but I'm nervous about it growing ridiculously
large. What if (eventually) setup.ini turns into XML? Do we put a
mingw build of libxml into 'mingw-libs'? How far does this go?
(visions of full{mingw}.exe)
OTOH, we've already discussed (and discarded, thank g-d) the idea of
(for instance) the zlib maintainer providing both a
cygwin-setup-installable zlib package (/usr/bin/cygz.dll,
/usr/lib/libz.[dll|a]) and a cygwin-setup-installable mingw-zlib package
(/usr/bin/mgwz.dll, /usr/lib/mingw/libz.[dll|a]). Ditto bzip2, libxml,
... we are not a mingw-porting factory.
2) The above won't work in a cross build environment. You could say
CC='i686-pc-cygwin-gcc -mno-cygwin'..., I guess.
for cross compiles:
../setup/configure --host=i686-pc-mingw32 --build-i686-pc-linux
should do it (assuming a mingw32 cross compiler is present), or a
combination using the CC string you have above with the mingw host will
work too.
whatever happened to the idea of an official cygwin package, that
contained a true cygwin-host, mingw-target cross compiler? Didn't
somebody or other volunteer to provide that?
(Granted, we still need 'cygwin-gcc -mno-cygwin' for the self-hosting
feature of cygwin1.dll, but there's no real need to *require* cygwin-gcc
-mno-cygwin for setup.exe, now that setup has been moved out of the
winsup tree)
anything that is non-simple. I haven't looked at it in a
while, though, so maybe things have changed.
It really depends on what you want to do. Some stuff it does
spectalularly well, some things it has trouble with. With the 'cross
compiling but not' approach, it would almost certainly have some trouble
:}.
see above, true cross compiler...
--Chuck
RE: setup changes to build standalone
A second issue is that I cannot get configure to play nice in the new location without updating to 2.5x. That doesn't concern me, does it concern anyone else? Not me. On a separate but related topic, I'd like to automakeise (is that a word) setup - if there are no objections from the other contributors. No, on the contrary I think that's a great idea. Raw Makefile.in's scare the hell out of me. ;-) -- Gary R. Van Sickle Brewer. Patriot.
RE: setup changes to build standalone
-Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Friday, April 26, 2002 2:07 PM To: [EMAIL PROTECTED] Subject: Re: setup changes to build standalone On Fri, Apr 26, 2002 at 01:44:32PM +1000, Robert Collins wrote: 2) The above won't work in a cross build environment. You could say CC='i686-pc-cygwin-gcc -mno-cygwin'..., I guess. for cross compiles: ../setup/configure --host=i686-pc-mingw32 --build-i686-pc-linux should do it (assuming a mingw32 cross compiler is present), or a combination using the CC string you have above with the mingw host will work too. Assuming you have a mingw cross compiler is what I was trying to avoid. For this purpose a 'gcc -mno-cygwin' compiler should work fine. I think the use of CC='i686-pc-cygwin-gcc -mno-cygwin' should work everywhere though. Cool. No issues there. Rob
RE: setup changes to build standalone
-Original Message-
From: Charles Wilson [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 26, 2002 2:12 PM
https://sourceforge.net/projects/mingwrep/
Thanks.
I wonder if we need a mingw-libs package.
Yes, please, please, yes. I would really really love it if
some of the
common libs (zlib, bz2lib, stdc++) where available in a setup.exe
installable pacakge.
Yes, I like this too -- but I'm nervous about it growing ridiculously
large. What if (eventually) setup.ini turns into XML? Do we put a
mingw build of libxml into 'mingw-libs'? How far does this go?
(visions of full{mingw}.exe)
glib + foo + bar + ...
If this sort of expansion were to occur, I'd suggest we take the
split-setup option and have a bootstrapping setup that is essentially
what we have today, but is only run once - ever. Then after that a
maintenance setup that is able to use cygwin linked tools.
OTOH, we've already discussed (and discarded, thank g-d) the idea of
(for instance) the zlib maintainer providing both a
cygwin-setup-installable zlib package (/usr/bin/cygz.dll,
/usr/lib/libz.[dll|a]) and a cygwin-setup-installable
mingw-zlib package
(/usr/bin/mgwz.dll, /usr/lib/mingw/libz.[dll|a]). Ditto
bzip2, libxml,
... we are not a mingw-porting factory.
Agreed.
whatever happened to the idea of an official cygwin package, that
contained a true cygwin-host, mingw-target cross compiler? Didn't
somebody or other volunteer to provide that?
I recall Danny talking about a gcc v 3.1 for April, but I'm not sure if
he meant as a cygwin package or as something else...
It really depends on what you want to do. Some stuff it does
spectalularly well, some things it has trouble with. With the 'cross
compiling but not' approach, it would almost certainly have
some trouble
:}.
see above, true cross compiler...
Yup. In fact gcc -mno-cygwin is close enough that automake won't be
confused... as long as it's told --host= :}.
Rob
RE: setup changes to build standalone
-Original Message- From: Robert Collins Sent: Friday, April 26, 2002 1:03 PM To: Cygwin-Apps Subject: setup changes to build standalone To build setup we need: a mingw bz2lib a mingw zlib and a mingw getopt. For now I'm putting this in the setup directory, but I'll almost certainly bundle it with libgetopt++ (as no symbols from it are needed by the setup sources). Rob
RE: setup changes to build standalone
-Original Message- From: Robert Collins Sent: Friday, April 26, 2002 3:28 PM To: Robert Collins; Cygwin-Apps Subject: RE: setup changes to build standalone -Original Message- From: Robert Collins Sent: Friday, April 26, 2002 1:03 PM To: Cygwin-Apps Subject: setup changes to build standalone To build setup we need: a mingw bz2lib a mingw zlib and a mingw getopt. For now I'm putting this in the setup directory, but I'll almost certainly bundle it with libgetopt++ (as no symbols from it are needed by the setup sources). sigh. And /src/winsup/cygwin/include/cygwin/version.h and /src/winsup/cygwin/include/sys/mount.h. For starters I'm just absorbing the content (only mount.cc needs them). However I think we should look at either a) having a mingw library for manipulating cygwin mount points officially available or b) having setup.exe call cygwin's mount.exe to setup the mount points in the first place, rather than setup being tightly linked to cygwin's registry format. c) some variation on the above themes. d) a --with-cygwin-headers=/path/to/headers and in mount.cc pickup the needed headers. Rob
