>
> 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 <[email protected]> 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 > [email protected] > http://two.pairlist.net/mailman/listinfo/scons-dev >
_______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
