This is the mail archive of the
gcc-patches@gcc.gnu.org
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.4020004@gmail.com> <4A291543.4030105@redhat.com> <4A291783.2030602@redhat.com> <4A291FF9.9060105@redhat.com> <4A2954AA.1050404@fgznet.ch> <4A2957A8.4080309@redhat.com> <b609cb3b0906051958k3109afc0pf12c40aadf8a0986@mail.gmail.com> <4A2A26F8.7050304@redhat.com> <20090607064416.GF8969@gmx.de> <m31vpur90n.fsf@fleche.redhat.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.
Andrew.