Java buidler does nothing when duplicate=1

[bdbaddog]

This issue was originally created at: 2009-11-10 19:46:24.
This issue was reported by: tmikov.
tmikov said at 2009-11-10 19:46:24

When using a variant_dir and duplicate=1, the Java builder silently does nothing. I this is the same issue as #913 and #1245, which is supposed to have been fixed, so perhaps this is a regression.

tmikov said at 2009-11-10 19:48:12

Created an attachment (id=652)
A simple project demonstrating the problem

gregnoel said at 2009-12-26 16:23:36

Bug party triage. We believe this is a case of SCons (like all build tools) assuming that a directory is up-to-date as long as it exists. The fix for this is SEP0001, so making this issue a dup of that tracking issue.

*** This issue has been marked as a duplicate of #2536 ***

tmikov said at 2009-12-26 17:34:30

For the record, I think you analysis is incorrect. The Java builder should not depend on directories, and as far as I know it doesn't. It scans the sources and generates a list of output class files.

Also, this doesn't explain why this only happens with "duplicate=1".

Other build tools (e.g. make) do not fail in this case.

One correct way to address this problem is to stop pretending that SCons supports Java builds. (Which wouldn't be a big loss, since 99.99% of Java projects use Maven or Ant)

paulbutcher said at 2010-02-11 02:53:44

This description (that scons is assuming that a directory is up to date as long as it exists) definitely does not explain the problem. I was going to attach a sample project to this bug to demonstrate, but actually the one that's already attached does so. The build fails whether or not the "out" directory exists.

This is not only a problem with the Java builder - it's a problem with any builder that makes use of DirScanner (e.g. Jar, Zip).

gregnoel said at 2010-02-12 06:10:06

Two users think this needs some more review, so reopening issue.

russel said at 2010-02-12 06:35:16

Comment required to add self as CC:

Should Java be added as a keyword?

gregnoel said at 2010-03-10 01:23:28

Bug party triage. Steven to research the issue, but not until 2.0 has been finished. Can be worked in conjunction with issue 2550.

gregnoel said at 2010-07-21 16:59:26

Bug party triage. Bump the priority of this issue.

gregnoel said at 2010-11-14 18:41:56

Promote issue so it will be reviewed at next bug party.

dirkbaechle said at 2010-12-01 17:13:06

Hi,

I debugged the given example a bit, and think that the problem lies in javac.py.

When the Java() Builder gets called in the SConscript, it tries to add the source files (*.java) from the source dir "src" to the results (javac.py, l.193). Via _create_nodes (Builder.py, l.553), the Emitter emit_java_classes() gets executed (Builder.py, l.517 -> javac.py, l.52). In lines 74-86 it should detect the Java source files, but fails when a variant dir is set (duplicate=1). In this case, the abspath of the variable dirnode points to the variant folder out/javaprj/src already...which does not exist yet. The os.walk() routine does not take this into account, and returns an empty list. -> No sources, and no targets to build!

In the attached Diff file, a quick'n'ugly hack tries to cure the symptoms by checking whether a variant dir was specified. If yes, a plain Node.Dir.glob() is used to extend the list of source files. This seems to work for the simple "bug1" testcase by Tzvetan, but there should be a more elegant solution available...ideas anyone?

Best regards,

Dirk

dirkbaechle said at 2010-12-01 17:17:25

Created an attachment (id=821)
Simple hack of javac.py, lets the bug1 example run successfully

tmikov attached bug1.zip at 2009-11-10 19:48:12.

A simple project demonstrating the problem

dirkbaechle attached patch_javac_quick_hack.diff at 2010-12-01 17:17:25.

Simple hack of javac.py, lets the bug1 example run successfully