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')).
The JavaDirBuilder already handles this really, but having a recursive Glob
could be a very powerful tool in general. You can build Java like Java(
'build', 'someDirTree' ) and javac with be invoked with all *.java files in
the directory tree. I think this builder is in SCons/Tools/__init__.py.
I'm not sure how it works, but you may find that useful.
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. ;)
I am actually trying to overhaul how the emitter for Java behaves. I think
that a new Node class similar to the Dir node will be required. The plan
is to make this Node a container of sorts and have the builder populate
the container on success. So now the container.up_to_date (real method
name here) will be able to handle this based on its contents. I realize
that the DAG will be technically incomplete prior to the first build, but
afterwards, it will be complete and rerunning would not necessarily require
a rebuild. This would also fix recursive dependency problems with the java
tools and reduce class group dependencies from O( n * m ) to O( 1 ) in
cases where class blob A depends on class blob B. I might not be able to
get it to work. I don't know if the current SCons builder framework can
support this notion, but hopefully, we can humor the thought long enough to
find out.
V/R,
William
On Sat, Aug 2, 2014 at 4:45 AM, Dirk Bächle tshor...@gmx.de wrote:
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
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
