Hi Mark,
On 02.08.2014 01:49, Mark A. Flacy wrote:
On Friday, August 01, 2014 05:22:39 PM William Blevins wrote:
SCons Java doesn't need to be that fancy, but I think the root problems can
be solved. The SCons java tool simply doesn't get the love that some of the
other tools get.
One common use case is to generate java source from the xjc tool (which
converts XML schema to java classes) for use by other java classes.
The emitter in that case would need to parse a bindings file as well as the XML
schema(s) that the binding file uses. However, the resulting java files should
have no dependencies on any external libraries, so they could be compiled as a
unit independently from anything using them.
And there are Annotations, which can be used to (and *are* used to) generate
source. See http://deors.wordpress.com/2011/09/26/annotation-types/ for a
discussion of how to do that.
it's okay to be concerned about "all the other possible Java use cases"
and I understand that it would be a long road to fully support the
toolchains you mentioned.
But this is not the scope of William's current investigations. He's
interested in improving the support for Java in SCons for the very basic
usage scenarios. And he has my full support, which doesn't mean a lot
because I don't have a large Java background but only some basic knowledge.
In the background, I'm working on a recursive Glob() which fully
supports Ant-like notation. Having this in place, we'd be able to link
generated Java sources (like in your examples above) into a SCons build
with commands like "env.Jar('build', Glob('*/**/*.java'))".
So one could at least schedule the generating commands for the *.java
files to run always, and then let SCons handle the rest.
This would still be far from perfect, but it's better than what we have
right now. And I, personally, am more interested in the latter. ;)
Just my 2 cents.
Best regards,
Dirk
_______________________________________________
Scons-dev mailing list
[email protected]
http://two.pairlist.net/mailman/listinfo/scons-dev
