Re: [Scons-dev] New symlink copy support
On Thu, Jul 31, 2014 at 2:27 AM, William Blevins wblevins...@gmail.com wrote: I see, I missed this fact from the commit. That makes sense, but documentation needs to be simplified IMO. https://bitbucket.org/scons/scons/commits/2e225b46b2ad10230ae0a11090a7a26101866989 Because I read symbolic link copying behavior in a wrong way. Provide a suggestion? I can barely read my own mind much less anyone else's :) What about this? +para +The Copy; factory supports copying symbolic links. This behavior can be controlled by an optional third argument. +/para + +para +Symbolic link shallow copied a new symbolic link: +/para + +para +literalCommand(LinkIn, LinkOut1, Copy($TARGET, $SOURCE[, True]))/literal +/para + +para +Symbolic link target copied as a file or directory: +/para + +para +literalCommand(LinkIn, FileOrDirectoryOut, Copy($TARGET, $SOURCE, False))/literal +/para =) I'd say this: para Since SCons 2.3.x Copy has symcopy keyword argument that controls how symlinks are copied. If set to True, symlinks will be copied as links, if False, SCons will copy file pointed by symlink. /para Positional arguments are bad, because from this: Copy($TARGET, $SOURCE, False) I can't say what False stands for. My first idea is dry-run. ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Java Development
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. I don't have the experience with the code base to know if my ideas are workable, so I will need some guidance. On Thu, Jul 31, 2014 at 11:04 PM, Mark A. Flacy mfl...@verizon.net wrote: On Sunday, July 27, 2014 03:10:34 PM William Deegan wrote: William, On July 25, 2014 at 8:27:02 PM, William Blevins (wblevins...@gmail.com) wrote: Team, I want to get another thread going for SCons Java development. The SCons Java tool has a ton of error reports on Tigris including 7 priority 1 issues. At the moment, this tool doesn't stand a chance against other Java competitors, and not because they are great tools. I frankly hate ANT. I have used Java support from SCons and it's seriously painful; nothing like the C++ support. Some other developers have made statements like No one outside SCons builds Java programs more complicated than hello world. The SCons tool framework is great, and I would really like to see the Java toolkit see some love. It has potential to be a hidden gem, and I want help out with this, but I don't have the experience to do this on my own, so firstly I'd like to list some of the biggest hurdles to users SCons Java. I'm not gonna try and propose any solutions at the moment. I just want to see if I can get the group thinking about the problems. 1. Adding resource files to a jar causes SCons segfault: http://scons.tigris.org/issues/show_bug.cgi?id=2550 I have firsthand experience with this bug. The only way I could figure out how to workaround it was to make a separate jar just for resources. 2. Java emitter almost never gets the java output correct. One of the many things I hate about ANT is that ANT is stupid. It always executes a build even if code is up-to-date and I usually have to explicitly clean. SCons COULD resolve both problems if the emitters worked. The only way to get remotely consistent working build is to call Jar( 'buildDir' ) when everyone wants to do Jar( [ 'class1', ... 'classN' ] ). 3. Dependencies: SCons does not automatically add classpath items as dependencies. Why do I need to do this manually? This is what SCons does! It's the heart and soul! I believe this is because of item #6. 4. Consistency: Classpath tokens (among other items) do not behave the same as other builders. Example: I cannot use #jar/item.jar in the classpath without expanding via something like File(...).get_path(). 5. Interfaces: Java(...) parameters and internal handling aren't intuitive and only handles sources = 'directory' correctly. It doesn't do lists of java files or list of directories in a sane manner. http://scons.tigris.org/issues/show_bug.cgi?id=1772 Personally, I don't think that Java and Jar should be separate functions. How do you get to the classes then? What about Javah! I have an idea, but that's outside the scope of this rant. 6. Performance: The dependency structure for Java exposes class files in a way that creates tons of false positives. SCons current: classes1 = Java(...) classes2 = Java(...) Depends( classes2, classes1 ) # O( N^2 ) dependency graph with tons of false positives SCons if I have anything useful to say about it jar1 = Jar( classes1 ) jar2 = Jar( classes2 ) Depends( jar2, jar1 ) # O( 1 ) which obviously fails in parallel builds currently. I am currently data mining a production Java codebase to prove my point. Dirk and I have already discussed this issue somewhat; thanks Dirk :) This actually causes the Task Master thread to get blocked on large jars reducing parallel efficiency in builds to None. The main issue here (if I understand SCons’ internals enough) is that SCons’s doing all dependencies on a per file basis. For many types of builds that works fine. For Java (building jars, and other issues) and some other types of builds, that’s very inefficient. There’s no “blob” of files where you have N inputs and M outputs, and thus you get the N*M arcs in the graph. Currently the only similar but not really similar enough is the Dir() Node type. But that has it’s own problems, which could be solved by a N*M type node. Other Java issues could likely be resolved building on top of such a new Node type. Though resolving the anonymous and inner classes in a java file creating more than one class file and what it might be named is also still an issue which the scanner and emitter try to solve by parsing the java files and figuring out the proper naming. This of course is not (as I understand it) formally defined as part of the java language and thus is a per compiler implementation detail. In my opinion, you are wasting your time. The way
Re: [Scons-dev] Java Development
We just updated in Parts trunk the Java tool. I believe it a few tweak based on the standard Scons tools. The note I have on this fix is “Fixed Java tool emitter to correctly handle derived targets.” You might want to look at it and see if it helps at all and is work grabbing into SCons. Here is a link the SVN file online.. http://parts.tigris.org/source/browse/parts/trunk/parts/parts/tools/javac.py?revision=516view=markup Jason From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of William Blevins Sent: Friday, August 1, 2014 4:23 PM To: SCons developer list Subject: Re: [Scons-dev] Java Development 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. I don't have the experience with the code base to know if my ideas are workable, so I will need some guidance. On Thu, Jul 31, 2014 at 11:04 PM, Mark A. Flacy mfl...@verizon.netmailto:mfl...@verizon.net wrote: On Sunday, July 27, 2014 03:10:34 PM William Deegan wrote: William, On July 25, 2014 at 8:27:02 PM, William Blevins (wblevins...@gmail.commailto:wblevins...@gmail.com) wrote: Team, I want to get another thread going for SCons Java development. The SCons Java tool has a ton of error reports on Tigris including 7 priority 1 issues. At the moment, this tool doesn't stand a chance against other Java competitors, and not because they are great tools. I frankly hate ANT. I have used Java support from SCons and it's seriously painful; nothing like the C++ support. Some other developers have made statements like No one outside SCons builds Java programs more complicated than hello world. The SCons tool framework is great, and I would really like to see the Java toolkit see some love. It has potential to be a hidden gem, and I want help out with this, but I don't have the experience to do this on my own, so firstly I'd like to list some of the biggest hurdles to users SCons Java. I'm not gonna try and propose any solutions at the moment. I just want to see if I can get the group thinking about the problems. 1. Adding resource files to a jar causes SCons segfault: http://scons.tigris.org/issues/show_bug.cgi?id=2550 I have firsthand experience with this bug. The only way I could figure out how to workaround it was to make a separate jar just for resources. 2. Java emitter almost never gets the java output correct. One of the many things I hate about ANT is that ANT is stupid. It always executes a build even if code is up-to-date and I usually have to explicitly clean. SCons COULD resolve both problems if the emitters worked. The only way to get remotely consistent working build is to call Jar( 'buildDir' ) when everyone wants to do Jar( [ 'class1', ... 'classN' ] ). 3. Dependencies: SCons does not automatically add classpath items as dependencies. Why do I need to do this manually? This is what SCons does! It's the heart and soul! I believe this is because of item #6. 4. Consistency: Classpath tokens (among other items) do not behave the same as other builders. Example: I cannot use #jar/item.jar in the classpath without expanding via something like File(...).get_path(). 5. Interfaces: Java(...) parameters and internal handling aren't intuitive and only handles sources = 'directory' correctly. It doesn't do lists of java files or list of directories in a sane manner. http://scons.tigris.org/issues/show_bug.cgi?id=1772 Personally, I don't think that Java and Jar should be separate functions. How do you get to the classes then? What about Javah! I have an idea, but that's outside the scope of this rant. 6. Performance: The dependency structure for Java exposes class files in a way that creates tons of false positives. SCons current: classes1 = Java(...) classes2 = Java(...) Depends( classes2, classes1 ) # O( N^2 ) dependency graph with tons of false positives SCons if I have anything useful to say about it jar1 = Jar( classes1 ) jar2 = Jar( classes2 ) Depends( jar2, jar1 ) # O( 1 ) which obviously fails in parallel builds currently. I am currently data mining a production Java codebase to prove my point. Dirk and I have already discussed this issue somewhat; thanks Dirk :) This actually causes the Task Master thread to get blocked on large jars reducing parallel efficiency in builds to None. The main issue here (if I understand SCons’ internals enough) is that SCons’s doing all dependencies on a per file basis. For many types of builds that works fine. For Java (building jars, and other issues) and some other types of builds, that’s very inefficient. There’s no “blob” of files where you have N inputs and M outputs, and thus you get the N*M arcs in the graph. Currently the only similar but not really similar enough is the Dir() Node type. But that has it’s own problems, which could be solved by a N*M
Re: [Scons-dev] Java Development
I can try to take a look at it, but if I understand correctly, the problem with the Java emitter is that there is no standard for how a Java compiler classes file creation, which means that the emitter needs to be different for every Java compiler. Which JDK do you use? V/R, William On Fri, Aug 1, 2014 at 5:49 PM, Kenny, Jason L jason.l.ke...@intel.com wrote: We just updated in Parts trunk the Java tool. I believe it a few tweak based on the standard Scons tools. The note I have on this fix is “Fixed Java tool emitter to correctly handle derived targets.” You might want to look at it and see if it helps at all and is work grabbing into SCons. Here is a link the SVN file online.. http://parts.tigris.org/source/browse/parts/trunk/parts/parts/tools/javac.py?revision=516view=markup Jason *From:* Scons-dev [mailto:scons-dev-boun...@scons.org] *On Behalf Of *William Blevins *Sent:* Friday, August 1, 2014 4:23 PM *To:* SCons developer list *Subject:* Re: [Scons-dev] Java Development 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. I don't have the experience with the code base to know if my ideas are workable, so I will need some guidance. On Thu, Jul 31, 2014 at 11:04 PM, Mark A. Flacy mfl...@verizon.net wrote: On Sunday, July 27, 2014 03:10:34 PM William Deegan wrote: William, On July 25, 2014 at 8:27:02 PM, William Blevins (wblevins...@gmail.com) wrote: Team, I want to get another thread going for SCons Java development. The SCons Java tool has a ton of error reports on Tigris including 7 priority 1 issues. At the moment, this tool doesn't stand a chance against other Java competitors, and not because they are great tools. I frankly hate ANT. I have used Java support from SCons and it's seriously painful; nothing like the C++ support. Some other developers have made statements like No one outside SCons builds Java programs more complicated than hello world. The SCons tool framework is great, and I would really like to see the Java toolkit see some love. It has potential to be a hidden gem, and I want help out with this, but I don't have the experience to do this on my own, so firstly I'd like to list some of the biggest hurdles to users SCons Java. I'm not gonna try and propose any solutions at the moment. I just want to see if I can get the group thinking about the problems. 1. Adding resource files to a jar causes SCons segfault: http://scons.tigris.org/issues/show_bug.cgi?id=2550 I have firsthand experience with this bug. The only way I could figure out how to workaround it was to make a separate jar just for resources. 2. Java emitter almost never gets the java output correct. One of the many things I hate about ANT is that ANT is stupid. It always executes a build even if code is up-to-date and I usually have to explicitly clean. SCons COULD resolve both problems if the emitters worked. The only way to get remotely consistent working build is to call Jar( 'buildDir' ) when everyone wants to do Jar( [ 'class1', ... 'classN' ] ). 3. Dependencies: SCons does not automatically add classpath items as dependencies. Why do I need to do this manually? This is what SCons does! It's the heart and soul! I believe this is because of item #6. 4. Consistency: Classpath tokens (among other items) do not behave the same as other builders. Example: I cannot use #jar/item.jar in the classpath without expanding via something like File(...).get_path(). 5. Interfaces: Java(...) parameters and internal handling aren't intuitive and only handles sources = 'directory' correctly. It doesn't do lists of java files or list of directories in a sane manner. http://scons.tigris.org/issues/show_bug.cgi?id=1772 Personally, I don't think that Java and Jar should be separate functions. How do you get to the classes then? What about Javah! I have an idea, but that's outside the scope of this rant. 6. Performance: The dependency structure for Java exposes class files in a way that creates tons of false positives. SCons current: classes1 = Java(...) classes2 = Java(...) Depends( classes2, classes1 ) # O( N^2 ) dependency graph with tons of false positives SCons if I have anything useful to say about it jar1 = Jar( classes1 ) jar2 = Jar( classes2 ) Depends( jar2, jar1 ) # O( 1 ) which obviously fails in parallel builds currently. I am currently data mining a production Java codebase to prove my point. Dirk and I have already discussed this issue somewhat; thanks Dirk :) This actually causes the Task Master thread to get blocked on large jars reducing parallel efficiency in builds to None. The main issue here (if I understand SCons’ internals enough) is that
Re: [Scons-dev] Java Development
For the tools here that use Java on the teams I know about use the standard JDK from Oracle. Jason From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of William Blevins Sent: Friday, August 1, 2014 5:03 PM To: SCons developer list Subject: Re: [Scons-dev] Java Development I can try to take a look at it, but if I understand correctly, the problem with the Java emitter is that there is no standard for how a Java compiler classes file creation, which means that the emitter needs to be different for every Java compiler. Which JDK do you use? V/R, William On Fri, Aug 1, 2014 at 5:49 PM, Kenny, Jason L jason.l.ke...@intel.commailto:jason.l.ke...@intel.com wrote: We just updated in Parts trunk the Java tool. I believe it a few tweak based on the standard Scons tools. The note I have on this fix is “Fixed Java tool emitter to correctly handle derived targets.” You might want to look at it and see if it helps at all and is work grabbing into SCons. Here is a link the SVN file online.. http://parts.tigris.org/source/browse/parts/trunk/parts/parts/tools/javac.py?revision=516view=markup Jason From: Scons-dev [mailto:scons-dev-boun...@scons.orgmailto:scons-dev-boun...@scons.org] On Behalf Of William Blevins Sent: Friday, August 1, 2014 4:23 PM To: SCons developer list Subject: Re: [Scons-dev] Java Development 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. I don't have the experience with the code base to know if my ideas are workable, so I will need some guidance. On Thu, Jul 31, 2014 at 11:04 PM, Mark A. Flacy mfl...@verizon.netmailto:mfl...@verizon.net wrote: On Sunday, July 27, 2014 03:10:34 PM William Deegan wrote: William, On July 25, 2014 at 8:27:02 PM, William Blevins (wblevins...@gmail.commailto:wblevins...@gmail.com) wrote: Team, I want to get another thread going for SCons Java development. The SCons Java tool has a ton of error reports on Tigris including 7 priority 1 issues. At the moment, this tool doesn't stand a chance against other Java competitors, and not because they are great tools. I frankly hate ANT. I have used Java support from SCons and it's seriously painful; nothing like the C++ support. Some other developers have made statements like No one outside SCons builds Java programs more complicated than hello world. The SCons tool framework is great, and I would really like to see the Java toolkit see some love. It has potential to be a hidden gem, and I want help out with this, but I don't have the experience to do this on my own, so firstly I'd like to list some of the biggest hurdles to users SCons Java. I'm not gonna try and propose any solutions at the moment. I just want to see if I can get the group thinking about the problems. 1. Adding resource files to a jar causes SCons segfault: http://scons.tigris.org/issues/show_bug.cgi?id=2550 I have firsthand experience with this bug. The only way I could figure out how to workaround it was to make a separate jar just for resources. 2. Java emitter almost never gets the java output correct. One of the many things I hate about ANT is that ANT is stupid. It always executes a build even if code is up-to-date and I usually have to explicitly clean. SCons COULD resolve both problems if the emitters worked. The only way to get remotely consistent working build is to call Jar( 'buildDir' ) when everyone wants to do Jar( [ 'class1', ... 'classN' ] ). 3. Dependencies: SCons does not automatically add classpath items as dependencies. Why do I need to do this manually? This is what SCons does! It's the heart and soul! I believe this is because of item #6. 4. Consistency: Classpath tokens (among other items) do not behave the same as other builders. Example: I cannot use #jar/item.jar in the classpath without expanding via something like File(...).get_path(). 5. Interfaces: Java(...) parameters and internal handling aren't intuitive and only handles sources = 'directory' correctly. It doesn't do lists of java files or list of directories in a sane manner. http://scons.tigris.org/issues/show_bug.cgi?id=1772 Personally, I don't think that Java and Jar should be separate functions. How do you get to the classes then? What about Javah! I have an idea, but that's outside the scope of this rant. 6. Performance: The dependency structure for Java exposes class files in a way that creates tons of false positives. SCons current: classes1 = Java(...) classes2 = Java(...) Depends( classes2, classes1 ) # O( N^2 ) dependency graph with tons of false positives SCons if I have anything useful to say about it jar1 = Jar( classes1 ) jar2 = Jar( classes2 ) Depends( jar2, jar1 ) # O( 1 ) which obviously fails in parallel builds currently. I am currently data mining a production Java codebase to prove my point. Dirk
Re: [Scons-dev] Java Development
On Friday, August 01, 2014 04:01:54 PM Bill Deegan wrote: Jason, Last I knew the output files differed by java version and not just java vendor.. ;) Any idea what version(s)? The outputs have not changed for the Oracle javac between 1.6 and 1.7. I don't know about 1.8, but it seems unlikely that it changed between 1.7 and 1.8. Easy enough to test if someone has Java 8 installed on their machine. -Bill On Fri, Aug 1, 2014 at 3:36 PM, Kenny, Jason L jason.l.ke...@intel.com wrote: For the tools here that use Java on the teams I know about use the standard JDK from Oracle. Jason *From:* Scons-dev [mailto:scons-dev-boun...@scons.org] *On Behalf Of *William Blevins *Sent:* Friday, August 1, 2014 5:03 PM *To:* SCons developer list *Subject:* Re: [Scons-dev] Java Development I can try to take a look at it, but if I understand correctly, the problem with the Java emitter is that there is no standard for how a Java compiler classes file creation, which means that the emitter needs to be different for every Java compiler. Which JDK do you use? V/R, William On Fri, Aug 1, 2014 at 5:49 PM, Kenny, Jason L jason.l.ke...@intel.com wrote: We just updated in Parts trunk the Java tool. I believe it a few tweak based on the standard Scons tools. The note I have on this fix is “Fixed Java tool emitter to correctly handle derived targets.” You might want to look at it and see if it helps at all and is work grabbing into SCons. Here is a link the SVN file online.. http://parts.tigris.org/source/browse/parts/trunk/parts/parts/tools/javac. py?revision=516view=markup Jason *From:* Scons-dev [mailto:scons-dev-boun...@scons.org] *On Behalf Of *William Blevins *Sent:* Friday, August 1, 2014 4:23 PM *To:* SCons developer list *Subject:* Re: [Scons-dev] Java Development 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. I don't have the experience with the code base to know if my ideas are workable, so I will need some guidance. On Thu, Jul 31, 2014 at 11:04 PM, Mark A. Flacy mfl...@verizon.net wrote: On Sunday, July 27, 2014 03:10:34 PM William Deegan wrote: William, On July 25, 2014 at 8:27:02 PM, William Blevins (wblevins...@gmail.com) wrote: Team, I want to get another thread going for SCons Java development. The SCons Java tool has a ton of error reports on Tigris including 7 priority 1 issues. At the moment, this tool doesn't stand a chance against other Java competitors, and not because they are great tools. I frankly hate ANT. I have used Java support from SCons and it's seriously painful; nothing like the C++ support. Some other developers have made statements like No one outside SCons builds Java programs more complicated than hello world. The SCons tool framework is great, and I would really like to see the Java toolkit see some love. It has potential to be a hidden gem, and I want help out with this, but I don't have the experience to do this on my own, so firstly I'd like to list some of the biggest hurdles to users SCons Java. I'm not gonna try and propose any solutions at the moment. I just want to see if I can get the group thinking about the problems. 1. Adding resource files to a jar causes SCons segfault: http://scons.tigris.org/issues/show_bug.cgi?id=2550 I have firsthand experience with this bug. The only way I could figure out how to workaround it was to make a separate jar just for resources. 2. Java emitter almost never gets the java output correct. One of the many things I hate about ANT is that ANT is stupid. It always executes a build even if code is up-to-date and I usually have to explicitly clean. SCons COULD resolve both problems if the emitters worked. The only way to get remotely consistent working build is to call Jar( 'buildDir' ) when everyone wants to do Jar( [ 'class1', ... 'classN' ] ). 3. Dependencies: SCons does not automatically add classpath items as dependencies. Why do I need to do this manually? This is what SCons does! It's the heart and soul! I believe this is because of item #6. 4. Consistency: Classpath tokens (among other items) do not behave the same as other builders. Example: I cannot use #jar/item.jar in the classpath without expanding via something like File(...).get_path(). 5. Interfaces: Java(...) parameters and internal handling aren't intuitive and only handles sources = 'directory' correctly. It doesn't do lists of java files or list
Re: [Scons-dev] Java Development
The issue is that we are guessing as to what syntax causes the compiler to emit an extra class file. On Fri, Aug 1, 2014 at 7:49 PM, Mark A. Flacy mfl...@verizon.net 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. I don't have the experience with the code base to know if my ideas are workable, so I will need some guidance. On Thu, Jul 31, 2014 at 11:04 PM, Mark A. Flacy mfl...@verizon.net wrote: On Sunday, July 27, 2014 03:10:34 PM William Deegan wrote: William, On July 25, 2014 at 8:27:02 PM, William Blevins ( wblevins...@gmail.com) wrote: Team, I want to get another thread going for SCons Java development. The SCons Java tool has a ton of error reports on Tigris including 7 priority 1 issues. At the moment, this tool doesn't stand a chance against other Java competitors, and not because they are great tools. I frankly hate ANT. I have used Java support from SCons and it's seriously painful; nothing like the C++ support. Some other developers have made statements like No one outside SCons builds Java programs more complicated than hello world. The SCons tool framework is great, and I would really like to see the Java toolkit see some love. It has potential to be a hidden gem, and I want help out with this, but I don't have the experience to do this on my own, so firstly I'd like to list some of the biggest hurdles to users SCons Java. I'm not gonna try and propose any solutions at the moment. I just want to see if I can get the group thinking about the problems. 1. Adding resource files to a jar causes SCons segfault: http://scons.tigris.org/issues/show_bug.cgi?id=2550 I have firsthand experience with this bug. The only way I could figure out how to workaround it was to make a separate jar just for resources. 2. Java emitter almost never gets the java output correct. One of the many things I hate about ANT is that ANT is stupid. It always executes a build even if code is up-to-date and I usually have to explicitly clean. SCons COULD resolve both problems if the emitters worked. The only way to get remotely consistent working build is to call Jar( 'buildDir' ) when everyone wants to do Jar( [ 'class1', ... 'classN' ] ). 3. Dependencies: SCons does not automatically add classpath items as dependencies. Why do I need to do this manually? This is what SCons does! It's the heart and soul! I believe this is because of item #6. 4. Consistency: Classpath tokens (among other items) do not behave the same as other builders. Example: I cannot use #jar/item.jar in the classpath without expanding via something like File(...).get_path(). 5. Interfaces: Java(...) parameters and internal handling aren't intuitive and only handles sources = 'directory' correctly. It doesn't do lists of java files or list of directories in a sane manner. http://scons.tigris.org/issues/show_bug.cgi?id=1772 Personally, I don't think that Java and Jar should be separate functions. How do you get to the classes then? What about Javah! I have an idea, but that's outside the scope of this rant. 6. Performance: The dependency structure for Java exposes class files in a way that creates tons of false positives. SCons current: classes1 = Java(...) classes2 = Java(...) Depends( classes2, classes1 ) # O( N^2 ) dependency graph with tons of false positives SCons if I have anything useful to say about it jar1 = Jar( classes1 ) jar2 = Jar( classes2 ) Depends( jar2, jar1 ) # O( 1 ) which obviously fails in parallel builds currently. I am currently data mining a production Java codebase to prove my point. Dirk and I have already discussed this issue somewhat; thanks Dirk :) This actually causes the Task
