Re: [JDBC] the build
От | Nic Ferrier |
---|---|
Тема | Re: [JDBC] the build |
Дата | |
Msg-id | 87d6jlklei.fsf@pooh-sticks-bridge.tapsellferrier.co.uk обсуждение исходный текст |
Ответ на | Re: [JDBC] the build (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-patches |
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
В списке pgsql-patches по дате отправления: