[ITP] gcc-tools-autoconf, gcc-tools-automake
Mon Jan 5 07:05:00 GMT 2009
Yaakov (Cygwin/X) wrote:
> Charles Wilson wrote:
>> Special versions of "pristine" (that is, no cygwin-special patches) of
>> autoconf-2.59 and automake-1.9.6 as required by gcc, installed into
> There's another, *much* simpler way to do this; .cygport attached. And
> yes, I would call it autoconf2.59.
> A special automake package is reqlly required as well?
Yes, because gcc requires the use of an unmodified automake. Our
existing 1.9.6 package is modified [*] -- and you can't have two
versions of the same minor automake release installed at the same time
in the same prefix.
Therefore, automake-1.9.6-pristine has to be installed "somewhere else"
-- e.g. not /usr. I take it as given that interoperable autotools must
all be installed in the same prefix [**] (can't remember the reasons
now, but I learned this the hard way many years ago). So,
autoconf-2.59-pristine has to be installed in that same "somewhere
else". E.g. not /usr.
So, it's not good enough to have /usr/bin/autoconf-2.59 and use the
existing /usr/bin/automake-1.9. We have to have new autoconf and
automake packages distinct from our existing ones, and they have to be
installed "somewhere else". /opt/gcc-tools/ seems reasonable. The
"difficulty" you observe is that cygport makes it hard -- and it SHOULD
be hard, I'm not pushing for a change -- to set the installation
directories to a custom prefix. (Yes, Mr. Boat-on-Water saying
sometimes you really need a road, with curbs, streetsigns, and traffic
This is just one of those cases where sometimes the easy was isn't the
[*] Inspection of the automake-1.9 cygport shows that the only code
changes in our automake are the libobj fixes (ignoring testsuite changes
and documentation). But, that means the generated Makefile.in's will be
different than ones created by pristine automake. Leading to
un-necessary (and thus, rejected) changes to those Makefile.in's when
Perhaps we could drop the libobj support from our am-1.9 packages? Sure,
but then IIRC cygwin libtool (1.5 only? also 2.2? Can't recall.) will
fail some of its regression tests -- with possible real-world
consequences for packages other than gcc/binutils.
Another idea: because our /usr/bin/automake-1.9 modifications directly
affect only the actual /usr/bin/automake-1.9 file itself (and not any of
the .m4 files and stuff in /usr/share/automake-1.9/), I *could* just
make a very small package that includes only a /usr/bin/automake-1.9bis
file, with a different alternatives priority. But the automake rules
don't know about AM_VERSION=1.9bis, only =1.9. So that won't work.
Third idea: A "sub-alternatives" arrangement for "ok, automake ->
automake-1.9, but automake-1.9 -> either "regular" or "gcc" am19". good
golly, no. That's just...ick. It would work, but...
So, IMO the least bad solution is a completely separate am-1.9-pristine
installed outside of /usr. And thus, ac-2.59 also installed outside of
/usr. It does mean that Dave has to remember to set his PATH properly --
but he can do that inside the gcc4.cygport once and for all.
[**] I'm cheating a bit with regards to libtool, as I haven't made a
gcc-tools-libtool package. But that's because I think it is probably not
necessary for Dave et. al. to try to update the libtool stuff in the gcc
tree; it's already at git-master post-2.2.6-release; Ralf W. has been
keeping it reasonably up to date; and you don't use libtoolize to do it,
anyway. You manually copy the relevant m4 files -- sadly, libtoolize
makes a hash of the src/ tree. At least it did the last time I tried to
do it that way.
More information about the Cygwin-apps