Re: [Scons-dev] Issues that can potentially be closed
On 12.07.2014 16:32, William Blevins wrote: For 1771, my protoc builder changes aren't important. This is not so much about importance, but traceability and being able to reproduce your findings later. Take a look at issue #1438 in the bug tracker. It's now suggested by Andrew to get closed, mainly because the error can't be reproduced...which later might happen to your issue too. I'm just sayin', it's still your decision. ;) Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Issues that can potentially be closed
In this case, the issue is a lot simpler than that because it has to do with the Java emitter directly. The test that I am trying to provide is a much better, general case test. If we solve that test, then we fix ALL derived source cases ;) On Sun, Jul 13, 2014 at 10:57 AM, Dirk Bächle tshor...@gmx.de wrote: On 12.07.2014 16:32, William Blevins wrote: For 1771, my protoc builder changes aren't important. This is not so much about importance, but traceability and being able to reproduce your findings later. Take a look at issue #1438 in the bug tracker. It's now suggested by Andrew to get closed, mainly because the error can't be reproduced...which later might happen to your issue too. I'm just sayin', it's still your decision. ;) Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Issues that can potentially be closed
On Saturday, July 12, 2014 06:18:09 PM William Blevins wrote:
There will certainly be cases where you would want both directories to be
compiled as a single unit.
And that's the question. Is it the responsibility of Java( ... ) to
combine the sources or the responsibility of the user. Do we want to allow
Java( ... ) to build anything in parallel or force the user to make
multiple Java( ... ) calls. This is more about making an interface choice
than fixing a bug.
I would say that one Java() invocation maps to one launch of javac. If you
give a list of directories to Java(), it handles them all at the same time.
If you want a lot of javac tasks in parallel, use multiple Java() builders.
Frankly, I don't see anyone using scons for java projects that more
complicated than Hello world or perhaps for testing a JNI implementation
(which would be useful indeed).
On Sat, Jul 12, 2014 at 6:09 PM, William Blevins wblevins...@gmail.com
wrote:
Still doesn't support it
On Sat, Jul 12, 2014 at 5:49 PM, Mark A. Flacy mfl...@verizon.net wrote:
On Saturday, July 12, 2014 10:22:18 AM William Blevins wrote:
2432 definitely duplicates 1772. The only difference is that 2432
proposes
a (bad) solution to the problem.
Both give the example:
Java('build',
[source1, source2],
JAVASOURCEPATH='src')
And explain that their issue is that source1 and source2 build in
parallel with separate javac commands; this is easily fixable with a
FLATTEN call, but we still haven't asked the important question. Is
this working as designed and the documentation needs to be updated to
reflect or is this a software failure?
V/R,
William
There will certainly be cases where you would want both directories to be
compiled as a single unit.
*Especially* if at least one of those directories contains autogenerated
source that is created by an earlier build step. (SCons didn't seem to
support this the last time that I thought about using it for Java, but
that
could be a faulty memory of mine.)
--
Mark A. Flacy
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
--
Mark A. Flacy
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Issues that can potentially be closed
On 10.07.2014 02:37, William Blevins wrote: *More duplicates (just looking at java issues atm):* 2432 -- Duplicates 1772 I'm not sure about this one. Gary, can you have a short look please? 1849 -- Duplicates 1594 2547 -- Duplicates 1594 2548 -- Duplicates 1594 2046 -- Duplicates 1594 2733 -- Duplicates 1594 Declared #2733 as the new parent bug. 2359 -- Duplicates 1766 No, one is about emitting proper class filenames for anonymous classes, the other about displaying the intermediate class names in the dependency tree output. 2931 -- Duplicates 1771 Okay, please attach your current modified version of the Protoc Builder to bug 1771 for later reference. 2483 -- Duplicates 2089 Good catch! Regards, Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Issues that can potentially be closed
On Sat, Jul 12, 2014 at 9:31 AM, Dirk Bächle tshor...@gmx.de wrote: On 10.07.2014 02:37, William Blevins wrote: *More duplicates (just looking at java issues atm):* 2432 – Duplicates 1772 I'm not sure about this one. Gary, can you have a short look please? I'm not a Java guy, but these two don't seem quite like dups. However perhaps the JAVASOURCEPATH var used in 1772 could do what the OP in 2432 wants (although it's not automatic, which 2432 is asking for). I'll put a quick note about that in 2432. -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Issues that can potentially be closed
2432 definitely duplicates 1772. The only difference is that 2432 proposes
a (bad) solution to the problem.
Both give the example:
Java('build',
[source1, source2],
JAVASOURCEPATH='src')
And explain that their issue is that source1 and source2 build in
parallel with separate javac commands; this is easily fixable with a
FLATTEN call, but we still haven't asked the important question. Is
this working as designed and the documentation needs to be updated to
reflect or is this a software failure?
V/R,
William
On Sat, Jul 12, 2014 at 10:06 AM, Gary Oberbrunner ga...@oberbrunner.com
wrote:
On Sat, Jul 12, 2014 at 9:31 AM, Dirk Bächle tshor...@gmx.de wrote:
On 10.07.2014 02:37, William Blevins wrote:
*More duplicates (just looking at java issues atm):*
2432 – Duplicates 1772
I'm not sure about this one. Gary, can you have a short look please?
I'm not a Java guy, but these two don't seem quite like dups. However
perhaps the JAVASOURCEPATH var used in 1772 could do what the OP in 2432
wants (although it's not automatic, which 2432 is asking for). I'll put a
quick note about that in 2432.
--
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Issues that can potentially be closed
On Sat, Jul 12, 2014 at 10:22 AM, William Blevins wblevins...@gmail.com
wrote:
2432 definitely duplicates 1772. The only difference is that 2432
proposes a (bad) solution to the problem.
Both give the example:
Java('build',
[source1, source2],
JAVASOURCEPATH='src')
And explain that their issue is that source1 and source2 build in parallel
with separate javac commands; this is easily fixable with a FLATTEN call, but
we still haven't asked the important question. Is this working as designed
and the documentation needs to be updated to reflect or is this a software
failure?
I see what you mean now, William. I'm OK with marking as dup. As for
your big question, again I'm not the right guy to say but my understanding
is javac works much better when all the .java files are passed on the same
invocation.
--
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Issues that can potentially be closed
Hi William; if you're talking about your addition
of test/Java/DerivedSourceTest.py, I don't see that in the latest source.
If you submit it as a pull request I'll merge it though.
On Sat, Jul 12, 2014 at 10:32 AM, William Blevins wblevins...@gmail.com
wrote:
For 1771, my protoc builder changes aren't important.
If my test patch made it into the scons trunk, then that is a good first
start. The test patch shows this as a derived source issue that works for
any case that *.java files are created and then compiled as steps within
scons.
At the time, I didn't have a bitbucket account or understand the scons
submission process. Do you know if that test case patch in the comment
made it into the scons code base?
V/R,
William
On Sat, Jul 12, 2014 at 10:22 AM, William Blevins wblevins...@gmail.com
wrote:
2432 definitely duplicates 1772. The only difference is that 2432
proposes a (bad) solution to the problem.
Both give the example:
Java('build',
[source1, source2],
JAVASOURCEPATH='src')
And explain that their issue is that source1 and source2 build in parallel
with separate javac commands; this is easily fixable with a FLATTEN call,
but we still haven't asked the important question. Is this working as
designed and the documentation needs to be updated to reflect or is this a
software failure?
V/R,
William
On Sat, Jul 12, 2014 at 10:06 AM, Gary Oberbrunner
ga...@oberbrunner.com wrote:
On Sat, Jul 12, 2014 at 9:31 AM, Dirk Bächle tshor...@gmx.de wrote:
On 10.07.2014 02:37, William Blevins wrote:
*More duplicates (just looking at java issues atm):*
2432 – Duplicates 1772
I'm not sure about this one. Gary, can you have a short look please?
I'm not a Java guy, but these two don't seem quite like dups. However
perhaps the JAVASOURCEPATH var used in 1772 could do what the OP in 2432
wants (although it's not automatic, which 2432 is asking for). I'll put a
quick note about that in 2432.
--
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
--
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Issues that can potentially be closed
Javac works with what you give it.
If there are dependencies between datasets, then they will not build;
otherwise, they will compile just fine. There are optimization concerns
though and here are some cases:
Java('build',
[source1, source2],
JAVASOURCEPATH='src')
Note: keep in mind that the javac call will multithread automatically;
I don't know if it default to 2 threads or to physical_core_count, but
there is some auto-optimization here.
Case 1:
source1 = [ 1.java, 2.java, #.java ]
source2 = [ a.java, b.java, n.java ]
This is probably fine since you are optimizing the compilation by
splitting of build trees.
Case 2:
source1 = 1.java
source2 = 2.java
sourceN = N.java
This is bad; there is a lot of overhead. Java builds are not
synonomous to c-like compiles.
Case 3:
source1 = dir1
source2 = dir2
This is essentially equivalent to case 1 and is fine.
---
Long story short, the sources should probably be flattened, but there
is also a performance issue with SCons java toolset atm which chokes
on Java( ... ) calls with a large number of source inputs. Dirk and I
have been discussing this on BitBucket and allowing for splitting of
files like this may be useful currently.
V/R,
William
On Sat, Jul 12, 2014 at 10:31 AM, Gary Oberbrunner ga...@oberbrunner.com
wrote:
On Sat, Jul 12, 2014 at 10:22 AM, William Blevins wblevins...@gmail.com
wrote:
2432 definitely duplicates 1772. The only difference is that 2432
proposes a (bad) solution to the problem.
Both give the example:
Java('build',
[source1, source2],
JAVASOURCEPATH='src')
And explain that their issue is that source1 and source2 build in parallel
with separate javac commands; this is easily fixable with a FLATTEN call,
but we still haven't asked the important question. Is this working as
designed and the documentation needs to be updated to reflect or is this a
software failure?
I see what you mean now, William. I'm OK with marking as dup. As for
your big question, again I'm not the right guy to say but my understanding
is javac works much better when all the .java files are passed on the same
invocation.
--
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Issues that can potentially be closed
On Saturday, July 12, 2014 10:22:18 AM William Blevins wrote:
2432 definitely duplicates 1772. The only difference is that 2432 proposes
a (bad) solution to the problem.
Both give the example:
Java('build',
[source1, source2],
JAVASOURCEPATH='src')
And explain that their issue is that source1 and source2 build in
parallel with separate javac commands; this is easily fixable with a
FLATTEN call, but we still haven't asked the important question. Is
this working as designed and the documentation needs to be updated to
reflect or is this a software failure?
V/R,
William
There will certainly be cases where you would want both directories to be
compiled as a single unit.
*Especially* if at least one of those directories contains autogenerated
source that is created by an earlier build step. (SCons didn't seem to
support this the last time that I thought about using it for Java, but that
could be a faulty memory of mine.)
--
Mark A. Flacy
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Issues that can potentially be closed
Still doesnt support it
On Sat, Jul 12, 2014 at 5:49 PM, Mark A. Flacy mfl...@verizon.net wrote:
On Saturday, July 12, 2014 10:22:18 AM William Blevins wrote:
2432 definitely duplicates 1772. The only difference is that 2432
proposes
a (bad) solution to the problem.
Both give the example:
Java('build',
[source1, source2],
JAVASOURCEPATH='src')
And explain that their issue is that source1 and source2 build in
parallel with separate javac commands; this is easily fixable with a
FLATTEN call, but we still haven't asked the important question. Is
this working as designed and the documentation needs to be updated to
reflect or is this a software failure?
V/R,
William
There will certainly be cases where you would want both directories to be
compiled as a single unit.
*Especially* if at least one of those directories contains autogenerated
source that is created by an earlier build step. (SCons didn't seem to
support this the last time that I thought about using it for Java, but that
could be a faulty memory of mine.)
--
Mark A. Flacy
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Issues that can potentially be closed
There will certainly be cases where you would want both directories to be
compiled as a single unit.
And that's the question. Is it the responsibility of Java( ... ) to
combine the sources or the responsibility of the user. Do we want to allow
Java( ... ) to build anything in parallel or force the user to make
multiple Java( ... ) calls. This is more about making an interface choice
than fixing a bug.
On Sat, Jul 12, 2014 at 6:09 PM, William Blevins wblevins...@gmail.com
wrote:
Still doesnt support it
On Sat, Jul 12, 2014 at 5:49 PM, Mark A. Flacy mfl...@verizon.net wrote:
On Saturday, July 12, 2014 10:22:18 AM William Blevins wrote:
2432 definitely duplicates 1772. The only difference is that 2432
proposes
a (bad) solution to the problem.
Both give the example:
Java('build',
[source1, source2],
JAVASOURCEPATH='src')
And explain that their issue is that source1 and source2 build in
parallel with separate javac commands; this is easily fixable with a
FLATTEN call, but we still haven't asked the important question. Is
this working as designed and the documentation needs to be updated to
reflect or is this a software failure?
V/R,
William
There will certainly be cases where you would want both directories to be
compiled as a single unit.
*Especially* if at least one of those directories contains autogenerated
source that is created by an earlier build step. (SCons didn't seem to
support this the last time that I thought about using it for Java, but
that
could be a faulty memory of mine.)
--
Mark A. Flacy
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Issues that can potentially be closed
William, On 11.07.2014 05:03, William Blevins wrote: I'm not sure how to progress with this? We discussed cleaning up the open issues in another thread, but I don't know enough about how issues are managed to be making changes without direction and/or get permission. I'll go through the Issue ML at Tigris over the weekend, and close the bugs that have been identified as resolved or duplicates by you and Andrew. Thanks again, you both did a great job! Also, there are lots of comments about bug triage, and I have no idea what that means. Don't care about them so much. We're in another bug triaging process right now, so only the issues we declare as important today really are... ;) Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
[Scons-dev] Issues that can potentially be closed
*Duplicates:* 1594, 1849, 2547, 2548 - Java() misses anonymous inner class file from private instances I recommend we close 3 of the 4 and move comments as necessary; no reason to have four P1 issues open for the same problem. *Might be a no issue:* 1772 – Java builder doesn't process lists of directories correctly Thoughts: elements of a list of sources for javac are executed in parallel which works as designed? Javac( buildDir, [ source1, source2, sourceN] ) Items source[1-N] are executed in parallel regardless of type (java file, directory, list of java files) Note: we should update the documentation to show this before closing. Question: do we want to change the behavior based on the type as listed above? Doing [ javac item for item in list of java files ] might not be very efficient but this makes a lot of sense of the other two options [ javac item for item in list of directories ] or [ javac item for item in list of lists of java files ]. V/R, William ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
