Re: [PATCHES] the build - Mailing list pgsql-jdbc

From Nic Ferrier
Subject Re: [PATCHES] the build
Date
Msg-id 87r881a383.fsf@pooh-sticks-bridge.tapsellferrier.co.uk
Whole thread Raw
In response to Re: [PATCHES] the build  (Barry Lind <blind@xythos.com>)
List pgsql-jdbc
Barry Lind <blind@xythos.com> writes:

> But isn't the meaning of JAVAC in the auto-tools different than you are
> using it for here?  Doesn't it mean the name of the executable that
> compiles java source in the auto-tools environment?  In ant it it a key
> word that represents the type of compiler so that you have things like
> 'classic' and 'modern' which are very different than anything the
> auto-tools would be generating.

You're right of course.


> > Ok. I'll look into developing one. I don't know much about it either
> > except that the task API has been pretty static and, since the tasks
> > are just bytecode, if you have Ant you can run any task.
> >
> How would this work?  Would the source for the task be part of cvs then
> a bootstrap process would be invoked to build the task first, then run
> ant a second time using that task?  It sounds like it could be very
> complex.

It wouldn't work like that. We'd set CLASSPATH to include our
pre-compiled ant task (there would be an Make/ANT target to build it
from source as well) in the call to ANT. It would then be available
to the build.


> I certainly agree that improvements could be made.  I look forward to
> seeing what you come up with.

I've got something that separates the targets out at the expense of
making the compilation specification include based. I'll make a proper
patch and send it tonight.


> As far as re-compiling the AbstractJdbc1* stuff, I do a 'make clean;
> make' to accomplish this.  Ugly, but it works.

Ah yes. That's what I do, and then I hack the build file so I don't
have to  /8->



Nic

pgsql-jdbc by date:

Previous
From: Barry Lind
Date:
Subject: Re: Index metadata not sorted by ORDINAL_POSITION
Next
From: "Cris"
Date:
Subject: Table as a column