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).
> 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.
> 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).
Nic