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

Nic Ferrier wrote:
> Barry Lind <blind@xythos.com> writes:
>
>
>>Nic,
>>
>>I think I would prefer using something other than JAVAC as the name.
>>Perhaps something like JAVA_COMPILER would be better.  Ant calls it
>>COMPILER but that clearly would be confusing.  JAVAC doesn't convey that
>>this is the type of compiler, instead it seems to indicate the compiler
>>executable name.
>
>
> It's just that JAVAC is the recognized name used by the
> auto-tools. It would mean consistency with the rest of the Make
> environment (if not the Ant environment, Ant really doesn't care).
>
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.

>
>
>>On the broader questions you are raising let me add the following comments.
>>
>>I am not against adding an ant task, but I don't know what that entails
>>or what the implications are for the build environment.  So in principal
>>I am OK with the idea, but reserve final judgment until after I
>>understand better the implications of it.
>
>
> 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.

>
>
>>Wouldn't it be simpler (although not as eligant) to just have different
>>targets for each of the jdbc versions?  If the target was the default
>>the current logic would be used, else if it was specified then just go
>>ahead and build that specific version.  This does get a bit complicated
>>with the different possible builds (jdbc1, jdbc2, jdbc2ee, jdbc2+ssl,
>>jdbc2ee+ssl, jdbc3), but I don't currently build all of these
>>permutations for posting to the website anyway, so I am not sure we need
>>them all to be available for cross-compilation either.
>
>
> Personally I think we need to clean up the Ant build anyway. IMHO
> it's a bit of a mess, I don't understand how to make it re-compile
> and AbstractJdbc1 file when I'm working on Java2 and I have to
> re-hack the build cript each time (I think you [or someone else]
> explained it to me once but it still wasn't very clear).
>
> So I'd be happy to look at creating explicit targets for jdbc1,
> jdbc2, jdbc3 and for the other permutations (which I'm sure we could
> handle smartly).
>
I certainly agree that improvements could be made.  I look forward to
seeing what you come up with.

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

thanks,
--Barry