Peter Eisentraut <peter_e@gmx.net> writes:
> Nic Ferrier writes:
>
> > The JAVAC variable in the Makefile.in is therefore designed to allow
> > overriding by the user when running the make, thus:
> >
> > ./configure --with-java ; make JAVAC=gcj
> >
> > will build the jdbc library with gcj.
>
> And then if you make a change and run make again but forget to specify the
> same Java compiler, you get a mess. Specifying variables on the make
> command line has been rejected as error-prone a long time ago.
I agree. If I ruled the world everything would be autotools.
The proposed patch is a hack. But it is a hack with a purpose, the
desire to do this is, after all, not exactly universal right now.
As I'm sure you know, a better solution would be to invent some kind
of autoconf macro to achieve the same purpose, ie: the specification
of the compiler to Ant. If it was done in autoconf then overrides
would be possible at ./configure time.
As Barry has pointed out, what we want the JAVAC variable (we'll
probably change the variable's name) to contain is not the filename
of a compiler executable but a symbolic name to be recognized by Ant;
so none of the existing autotools Java macros is suitable.
And I don't have the time _right_ now to write such a macro. I might
in the future.
So, is the hack method totally unacceptable do you think? If not I'll
submit it as part of a patch for the java build that I'll be doing
this evening.
If it is unacceptable then we'll have to wait for somebody to write a
macro before compiling with gcj becomes easier (and I think that
would be a pity).
Nic