Re: [ITP] gcc-tools-autoconf, gcc-tools-automake

[Charles Wilson <cygwin@cwilson.fastmail.fm>]

Yaakov (Cygwin/X) wrote:
> Charles Wilson wrote:
> In what way does gcc "require" a vanilla automake?  Below you say that
> the only difference is some libobj fixes.  To me that means that gcc
> will build, but the patches won't be quite right (meaning that gcc keeps
> Makefile.in in CVS?).  That's not exactly what I call "requiring".

Many -- if not most -- of Dave's changes are *build system* fixes.
Modifying Makefile.am's and such. And yes, gcc keeps Makefile.in's under
source control. So, many of Dave's patches to send upstream will contain
changes to Makefile.in's as generated by automake.

If he's using the wrong automake -- or a patched version of the right
automake -- that just makes his life harder. The point of these packages
is to make life easier.

I'm not providing these packages so that gcc will build on cygwin. I'm
(attempting to) provide them to ease the development of gcc on cygwin --
a subtle difference, and one that includes considerations such as "make
it easy(ier) to send patches upstream with a reasonable likelihood of
acceptance".

The gcc website explicitly states "automake 1.9.6" -- not debian's
patched version, or cygwin's patched version, or something that claims
to be 1.9.6 but includes all substantive changes from 1.10.1. "For
directories that use automake, GCC requires the latest release in the
1.9.x series, which is currently 1.9.6. When regenerating a directory to
a newer version, please update all the directories using an older 1.9.x
to the latest released version."

>> ...libobj...
> 
> It would be good to know if the automake patches are no longer needed
> with libtool-2.2, but for now let's assume the worst.
> 
>> [**] ...libtool...
> 
> Our libtool is basicall vanilla anyway; the LT_OUTPUT patch (which
> anyways I'm not sure that we need anymore) wouldn't be relevant here.

True, but in this case I was referring more to the fact that
/opt/gcc-tools/ doesn't contain libtool at all, which means "all
autotools in the same prefix" is being violated. My argument was "all
autotools /that we intend to use/" are still in the same prefix --
because (I hope) Dave doesn't intend to re-libtoolize.

--
Chuck