This is the mail archive of the
mailing list for the GCC project.
Re: libffi merge
- From: Andrew Haley <aph at redhat dot com>
- To: Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>, Tom Tromey <tromey at redhat dot com>, Andrew Haley <aph at redhat dot com>, NightStrike <nightstrike at gmail dot com>, Andreas Tobler <andreast-list at fgznet dot ch>, Dave Korn <dave dot korn dot cygwin at googlemail dot com>, Anthony Green <green at moxielogic dot com>, Anthony Green <green at redhat dot com>, libffi-discuss at sourceware dot org, gcc-patches <gcc-patches at gcc dot gnu dot org>, Java Patch List <java-patches at gcc dot gnu dot org>
- Date: Mon, 08 Jun 2009 19:32:43 +0100
- Subject: Re: libffi merge
- References: <4A290E5D.email@example.com> <4A291543.firstname.lastname@example.org> <4A291783.email@example.com> <4A291FF9.firstname.lastname@example.org> <4A2954AA.email@example.com> <4A2957A8.firstname.lastname@example.org> <email@example.com> <4A2A26F8.firstname.lastname@example.org> <20090607064416.GF8969@gmx.de> <email@example.com> <20090608182542.GA32471@gmx.de>
Ralf Wildenhues wrote:
> Hello Tom,
> * Tom Tromey wrote on Mon, Jun 08, 2009 at 06:21:44PM CEST:
>>>>>>> "Ralf" == Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
>> Ralf> Would standalone libffi be willing to accept into its tree
>> Ralf> configury parts that are only active in the GCC tree?
>> If this is possible, why have a separate libffi repository at all?
>> You could just tell developers to:
>> svn co svn://gcc.gnu.org/svn/gcc/trunk/libffi
> Sorry to have given the impression, but what I meant was that I think
> it is possible to have almost zero differences in configure.ac and
> Makefile.am files; the trees however also store generated files.
> For one, I wouldn't know to eliminate the ACLOCAL_AMFLAGS setting used
> in gcc/libffi/Makefile.am, leading to differences in the aclocal.m4
> file. And the AM_ENABLE_MULTILIB in configure.ac can easily be made
> conditional at the m4 level (i.e., at autoconf run time), but probably
> leaves at least some traces if only done at configure run time.
Yeah, and I don't think we need to. A few small differences like this
IMO don't hurt at all. Once everything is in sync, keeping it in sync
is easy. The problem has been that there has been a fair bit of
divergence that looks to me like it was intended. But never mind that,
we're nearly there now.