This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Classpath Merge (1/3): libgcj-import-20100921


On 5 October 2010 19:04, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> Hello,
>
> * Matthias Klose wrote on Tue, Oct 05, 2010 at 10:43:55AM CEST:
>> On 28.09.2010 23:23, Dr Andrew John Hughes wrote:
>> >Attached is a merge of GNU Classpath into trunk from the tag
>> >libgcj-import-20100921. ÂThis tag was created against revisions as of
>> >2010-06-01 to avoid the whitespace changes on the 3rd. ÂMy intention
>> >is to post separate whitespace fixes for gcj and then a second merge
>> >containing changes after this change to Classpath. ÂThis merge however
>> >contains most of the changes that have lingered in Classpath for a
>> >long time since the merge for 4.4.
>> >
>> >This took longer than expected, mainly due to the presence of
>> >generated autotools files in the gcj tree which require regeneration
>> >with specific versions. Âgcj seems to have decided to use libtool
>> >2.2.7a, which doesn't exist as a release on
>> >http://ftp.gnu.org/gnu/libtool/ and I ran into conflicts with macros
>> >from the GNU Classpath import which used the system 2.2.10 install.
>> >In the end, the solution was to remove the Classpath copy from the m4
>> >directory, which caused the 2.2.7a macros in
>> >the top-level config directory to be used.
>>
>> CCing Ralf for the auto*/libtool stuff. Maybe it's worth documenting the
>> missing libtool bits/versions in libjava/HACKING?
>
> FWIW, I intend to update Libtool bits in GCC to 2.4 before 4.6, not the
> least in order to get LTO working throughout the tree.
>
> Inside GCC, it is important that you pick up toplevel and
> toplevel/config directories for aclocal (ACLOCAL_AMFLAGS = -I .. -I
> ../config) so that override.m4 is found.
>
> configure.ac:
>> +if ...
>> +...
>> +else
>> + Â AM_CONDITIONAL(GCJ_JAVAC, no)
>> Âfi
>
> Having an AM_CONDITIONAL in a shell conditional leads to trouble.
> Instead, use the shell condition inside an AM_CONDITIONAL at outer
> level:
>
> ÂAM_CONDITIONAL([GCJ_JAVAC], [test "$foo" = bar])
>
> Cheers,
> Ralf
>

We already do that in libjava/classpath/m4/ac_prog_javac.m4:

AM_CONDITIONAL(GCJ_JAVAC, test x"${JAVAC_IS_GCJ}" = xyes)

The addition above is necessary because we can't compute JAVAC_IS_GCJ
if java maintainer mode is turned off as there is no javac.

It's not ideal, I agree.  I'll see if I can find a better solution.

-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FAÂ 7927 142C 2591 94EF D9D8


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]