Hi William,
please find a few comments below.
On 30.05.2014 02:42, William Blevins wrote:
Team,
I have a couple points I'd like to discuss, but for the sake of
organization, I intend to split them into separate emails.
Java Part #2
There has been some discussion on making Scons more ANT-like,
http://www.scons.org/wiki/JavaSupport, and that might solve some
issues like identifying Java targets. There is merit here assuming
that Java support stays SCons-like at the same time; otherwise, why
not just use ant or maven?
From this I get that you'd like to have some form of Java support in
SCons directly, and don't want to delegate things to an external
program, correct? At least it's my assumption for the following remarks...
Problem(s) this will solve:
1. Determining the source -> target(s) from *.java -> *.class is
painful, possibly java version dependent, and performance intensive
(possibly); thus, we should optimize this out.
2. Java developers are plagued requiring manual cleaning of a jar far
too often with ant-like system(s) and the current scon(s) methodology.
1. Clean could be required when deleting or moving a file since the
last build output isn't removed otherwise; avoidable in current SCons
depending on how sources are specified (not obvious and/or intuitive
coming from ant-like system(s)).
3. Simplify the SCons Java API to allow building jar file(s) without
having to interact with *.class file(s) at all.
4. Simplify the SCons Java support for resource file(s); currently,
you have to do copying by hand (if it's supported I know not where or
how).
5. Reduce the amount of code required to build a jar (by a lot).
This sounds like an even more simplified Java Builder than what we have
now. If you could come up with a SoSimpleJava() Builder, we'd probably
add it to the core and let people have their own choice.
How I imagine this should work:
1. Treat class file(s) like side-effect(s) and do not include them (at
all) in the dependency tree.
1. This means we don't have to scan the Java file(s) and determine
*.class targets.
I don't think that you can have both. If you treat files as SideEffects
(in the SCons sense), they have to be part of the dependency DAG. See
next comment...
2. Remove the Java(...) function from SCons; thus, do not interact
with *.class file(s) directly ever. There isn't a *good* reason to do
this.
Here is just one scenario, where dealing with *.class files actually
makes sense: If you're using anonymous classes in a Java source, a bunch
of additional class files get generated. How do you remove these files
on a "clean", if they are located in a source folder (which people might
prefer for some reason)?
More experienced Java developers can probably come up with a dozen more
useful cases...I'm not sure how often people would want to integrate
pre-built *.class files (coming from Scala perhaps?) into their builds,
for example.
You may be able to work around the "clean" problem, by creating all
"*.class" files in a separate folder structure (pretty much like a
VariantDir). But what you'll end up with is a somewhat crippled DAG,
forcing you to remove this output dir completely and rebuild everything
from scratch...even when only a comment in a single Java source is
changed. Only to "be sure", just like in make or Ant...there is not much
of a win here for the user, I'm afraid.
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?
Finally, you should take into account that users might want to create
different versions of the same source code. Just as an example, let's
assume they want to create an "original" and "obfuscated" target(s), or
a "simple" and "extended" release where additional packages get included
based on environment variables. And for maximum speedup they do this in
parallel, by using the "-j" option...so a single dedicated output dir
won't do probably.
Best regards,
Dirk
_______________________________________________
Scons-dev mailing list
[email protected]
http://two.pairlist.net/mailman/listinfo/scons-dev
