On Sep 6, 2012, at 13:21 , Greg Ward <[email protected]> wrote:
> On 06 September 2012, Chris BeHanna said:
>> On Sep 5, 2012, at 21:20 , Greg Ward <[email protected]> wrote:
>>
>>> OK, I finally sat down and did a little thought experiment, and have
>>> convinced myself that file-based buld tools will never handle Java.
>>> The reason? Dependency cycles.
>>
>> I wonder if it's even anything to worry about. Have a .jar as
>> output and a defined set of .java files as input, and in the middle,
>> it's sausage-making. Don't even worry about tracking (or caching)
>> .class files; just track the dependency of a .jar file to its .java
>> files. As long as all of the .class files (even those that end up
>> being generated anonymously) end up in a predetermined location over
>> which you run the jar command, you should be good to go.
>
> Yup, that's exactly what I ended up doing at my old job, where I
> cobbled together a moderately scary mixed C++/Java build system using
> SCons and a lot of hard work. It was harder than it should have been,
> mainly because I had to write a custom Node class to represent the set
> of input files. SCons is just too slow when you give it 15,000 input
> files, but it was tolerable when I shrank it down to ~75 sets of input
> files. Writing custom Node classes that do not subclass File is a
> PITA.
:nod:
That performance hit is why $EMPLOYER is abandoning SCons. :-(
> However, something valuable is lost when you simplify dependencies so
> dramatically. Specifically, I implemented incremental testing, which
> was a win, but not nearly as much of a win as it could have been. E.g.
> if you modify a source file in a low-level component that everything
> else depends on, then you end up recompiling the world (no big deal:
> javac is fast enough), and re-running all the tests (not nice: the
> whole test suite is 20-30 min).
Can the tests be broken down to a per-jar basis? If so, and if you can
identify the jar or jars that changed, then you only run the tests for the jars
that changed.
--
Chris BeHanna
[email protected]
_______________________________________________
Scons-dev mailing list
[email protected]
http://two.pairlist.net/mailman/listinfo/scons-dev
