Re: [PATCHES] the build
От | Nic Ferrier |
---|---|
Тема | Re: [PATCHES] the build |
Дата | |
Msg-id | 87r881a383.fsf@pooh-sticks-bridge.tapsellferrier.co.uk обсуждение исходный текст |
Ответ на | Re: [PATCHES] the build (Barry Lind <blind@xythos.com>) |
Список | 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 по дате отправления: