* Re: Automake versions (was: Patch to make libgcj work with autoreconf again)
@ 2005-08-23 18:29 Benjamin Kosnik
2005-08-23 18:43 ` DJ Delorie
0 siblings, 1 reply; 6+ messages in thread
From: Benjamin Kosnik @ 2005-08-23 18:29 UTC (permalink / raw)
To: gcc; +Cc: tromey, pinskia, kcook, java-patches
Thanks Tom for pointing this out. We have to all keep these autotools
versions synced: it bugs everybody to have extraneous differences in
trees due to version mis-match.
>Unfortunately, we have automake 1.9.3, 1.9.4 and 1.9.5 floating
>throughout the tree.
How did this happen?
>I propose standardizing the entire tree on 1.9.6,
>as it is the current release; moreover the 1.9 branch has only had a
>few minor patches since 1.9.6 was released 6 weeks ago so 1.9.6 might
>be stable for a while.
I am in support of this. The sooner the better.
>> Probably we should have a script in contrib/ that downloads and
>> builds all the currently-required tool versions.
>This would be very cool.
That seems like the only solution to end this continual issue. I'm strongly in favor of it.
-benjamin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Automake versions (was: Patch to make libgcj work with autoreconf again)
2005-08-23 18:29 Automake versions (was: Patch to make libgcj work with autoreconf again) Benjamin Kosnik
@ 2005-08-23 18:43 ` DJ Delorie
2005-08-23 19:26 ` Benjamin Kosnik
0 siblings, 1 reply; 6+ messages in thread
From: DJ Delorie @ 2005-08-23 18:43 UTC (permalink / raw)
To: bkoz; +Cc: gcc, tromey, pinskia, kcook, java-patches
> Thanks Tom for pointing this out. We have to all keep these
> autotools versions synced: it bugs everybody to have extraneous
> differences in trees due to version mis-match.
Could we modify the CVS commit filters to *require* the right
versions? If it detects a commit with the wrong version (at least,
assuming the old rev had the right version), it can just reject it.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Automake versions (was: Patch to make libgcj work with autoreconf again)
2005-08-23 18:43 ` DJ Delorie
@ 2005-08-23 19:26 ` Benjamin Kosnik
2005-08-23 22:44 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: Benjamin Kosnik @ 2005-08-23 19:26 UTC (permalink / raw)
To: DJ Delorie; +Cc: gcc, tromey, pinskia, kcook, java-patches
> Could we modify the CVS commit filters to *require* the right
> versions? If it detects a commit with the wrong version (at least,
> assuming the old rev had the right version), it can just reject it.
Dunno if this is possible, but this would be great. It would be nice if
there was a way to set different versions per branch. For instance, the
gcc-4_0-branch, gcc-3_4-branch, and mainline might have different
autotools requirements.
-benjamin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Automake versions (was: Patch to make libgcj work with autoreconf again)
2005-08-23 19:26 ` Benjamin Kosnik
@ 2005-08-23 22:44 ` Ian Lance Taylor
0 siblings, 0 replies; 6+ messages in thread
From: Ian Lance Taylor @ 2005-08-23 22:44 UTC (permalink / raw)
To: Benjamin Kosnik; +Cc: DJ Delorie, gcc, tromey, pinskia, kcook, java-patches
Benjamin Kosnik <bkoz@redhat.com> writes:
> > Could we modify the CVS commit filters to *require* the right
> > versions? If it detects a commit with the wrong version (at least,
> > assuming the old rev had the right version), it can just reject it.
>
> Dunno if this is possible, but this would be great.
This is possible--the file to modify is CVSROOT/commitinfo, to run
some script for a specific set of files.
It would be nice if
> there was a way to set different versions per branch. For instance, the
> gcc-4_0-branch, gcc-3_4-branch, and mainline might have different
> autotools requirements.
I'm not sure this is available. It might be possible to look in
CVS/Tag to find the branch tag for the file. I don't know whether
that file is certain to exist when commitinfo is run, but it seems
that it might.
Ian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Automake versions (was: Patch to make libgcj work with autoreconf again)
2005-08-23 18:26 ` Kelley Cook
@ 2005-08-23 20:32 ` Tom Tromey
0 siblings, 0 replies; 6+ messages in thread
From: Tom Tromey @ 2005-08-23 20:32 UTC (permalink / raw)
To: kcook; +Cc: Andrew Pinskia, java-patches, GCC Mailing List
>>>>> "KC" == Kelley Cook <kcook@gcc.gnu.org> writes:
KC> Unfortunately, we have automake 1.9.3, 1.9.4 and 1.9.5 floating
KC> throughout the tree. I propose standardizing the entire tree on 1.9.6,
KC> as it is the current release; moreover the 1.9 branch has only had a
KC> few minor patches since 1.9.6 was released 6 weeks ago so 1.9.6 might
KC> be stable for a while.
This sounds great to me.
>> Probably we should have a script in contrib/ that downloads and
>> builds all the currently-required tool versions.
KC> This would be very cool.
I submitted one.
Tom
^ permalink raw reply [flat|nested] 6+ messages in thread
* Automake versions (was: Patch to make libgcj work with autoreconf again)
[not found] <m34q9g1udt.fsf@localhost.localdomain>
@ 2005-08-23 18:26 ` Kelley Cook
2005-08-23 20:32 ` Tom Tromey
0 siblings, 1 reply; 6+ messages in thread
From: Kelley Cook @ 2005-08-23 18:26 UTC (permalink / raw)
To: tromey, Andrew Pinskia; +Cc: java-patches, GCC Mailing List
--- Tom Tromey <tromey@redhat.com> wrote:
> >>>>> "KC" == Kelley Cook <kcook@gcc.gnu.org> writes:
>
> KC> 2005-08-19 Kelley Cook <kcook@gcc.gnu.org>
> KC> * Makefile.am (ACLOCAL_AMFLAGS): Also include "..".
> KC> * acinclude.m4: Delete. Extract CHECK_FOR_BROKEN_MINGW_LD to
> ...
> KC> * mingwld.m4: ... this new file.
> KC> * aclocal.m4, Makefile.in, gcj/Makefile.in: Regenerate.
> KC> * include/Makefile.in, testsuite/Makfile.in: Regenerate.
>
> You used automake 1.9.4 to build Makefile.in.
Yes, Andrew had used 1.9.4 in his patch
(http://gcc.gnu.org/ml/gcc-cvs/2005-08/msg00618.html) from a few days
before, so I did also. I actually had to download that version first.
> AIUI, with the exception of libgfortran, the tree is currently
> standardized on automake 1.9.3. I wouldn't mind an update, but it
> ought to be done globally and install.texi ought to be updated.
> Meanwhile, having folks using different versions causes cvs churn...
Unfortunately, we have automake 1.9.3, 1.9.4 and 1.9.5 floating
throughout the tree. I propose standardizing the entire tree on 1.9.6,
as it is the current release; moreover the 1.9 branch has only had a
few minor patches since 1.9.6 was released 6 weeks ago so 1.9.6 might
be stable for a while.
>
> Probably we should have a script in contrib/ that downloads and
> builds all the currently-required tool versions.
This would be very cool.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-08-23 21:46 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-08-23 18:29 Automake versions (was: Patch to make libgcj work with autoreconf again) Benjamin Kosnik
2005-08-23 18:43 ` DJ Delorie
2005-08-23 19:26 ` Benjamin Kosnik
2005-08-23 22:44 ` Ian Lance Taylor
[not found] <m34q9g1udt.fsf@localhost.localdomain>
2005-08-23 18:26 ` Kelley Cook
2005-08-23 20:32 ` Tom Tromey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).