[Scons-dev] SCons and Java

[William Blevins]

Dirk,

thanks for your quick reply.


I really wanted to reply sooner, but I can't get access to private email
during the day except on my phone.

That's good to hear, any helping hand is welcome. I haven't been involved
> in the latest Java development, so the link list I gave you in the mailing
> thread
> http://four.pairlist.net/pipermail/scons-users/2014-February/002225.html is
> all I got.


Thanks!

Testing out this idea looks like a straightforward task to me. I'd really
> like to encourage you to just go ahead and implement a new Tool/Builder in
> parallel to the existing ones. Then it's easier to discuss dis-/advantages
> and point out the problems of each approach.


> However, there certainly will be more obstacles ahead that I can't think
> of right now. It's a perfectly understandable reaction to restrict
> functionality, such that certain issues don't even emerge in first place.
> But one has to be careful about not driving this too far, because then it's
> actually more "problem avoidance" than "problem solving".
>

I agree here.  There is a fine line between the two.  I don't necessarily
want to restrict the user too much but sometimes a little restriction can
also save the user from themselves.  I've seen build system(s) for some
older/mature products and I WISH that someone would have restricted them
from digging there own grave.  Often the simplest answer is the right
answer.

I'd really like to have a look at your performance measurements. Perhaps
> you can push them up to a public repo, like I did for
> https://bitbucket.org/dirkbaechle/scons_testresults ? Then you can
> publish your full set of data (plus supporting scripts and whatever else
> would be required to reproduce your results), and just have to pass the URL
> around.


I cannot publish the source code, but I have SCons performance profile(s)
for v2.2.0 and v2.3.0, sample SConscript(s), and pystat trace(s).  That
should be all we need to bound the issue.

It could also be several JARs, that the user tries to build in parallel. So
> you'll have to ensure that the single output dirs don't ever clash, by
> using temporary names for example.


That would be the idea.  All the parallel portion would still work as
desired; I'm actually trying to improve it.  In fact, as I mentioned in an
afterthought email:

Users might also accidentally delete "*.class" files in your output dir,
> between two builds. And they expect SCons to rebuild those intermediate
> targets on its next invocation. How do you want to handle this?



SCons wouldn't rebuild since no source had changed.  This would be an issue
>> if the user was trying to share *.class file(s) which would only be
>> relevant with something like SCons.JavaH, but it supports the directory
>> parameter(s). SCons could check that the directory contents had changed and
>> mark as requiring rebuild; I am grabbing at straws on this one...
>
>
>> In the case of SCons.JavaH, you would probably want to denormalize the
>>> build.  This might sound terrible at first, but it work(s) well in some
>>> database implementation(s) requiring high-speed throughput.
>>
>>
>>> JavaH work make a separate Java compiler invocation.  It would require
>>> more overall work, but the build would be correct, and the target directory
>>> could be cleaned up after Java/JavaH call(s) since the file(s) are waste
>>> product(s) of the process and wouldn't be tracked in the DAG.
>>
>>
If the SCons team has every thought of trying to make SCons clusterable
like distcc, it may prove immensely faster to denormalize the build in
cases like this than to copy file(s) between machines.

V/R,
William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140531/ef3faadc/attachment.html>