作为相当复杂的跨平台构建的一部分，我调用了 SCons Java 构建器。.java 文件 *是从模板自动生成的。它们包含包信息：package com.example.package;并在目录中相应地布局。src/com/example/package/MyClass.java
征兵：
# javaSources is the absolute path to each java file i.e src/com/example/package/MyClass.java
# outputClassesPath is classes/
JavaArtifacts = env.Java(target = outputClassesPath, source = javaSources)
对 scons 的第一次调用正确构建了 MyClass.java 并将输出放入classes/com/example/package/MyClass.class
如果我再次调用 scons - 没有任何变化 - javac 命令将再次运行。使用scons --debug=explain我得到：
scons: building 'classes/MyClass.class' because it doesn't exist
这是真的——但classes/com/example/package/MyClass.class确实存在！
对我来说，这看起来像是 SCons 中的一个错误。似乎 SCons 在正确的位置正确地创建了 .class 文件，但它的第一遍似乎并不知道这个正确的位置在哪里。
更新：Java 文件由模板引擎（使用env.Command模式调用）创建。模板引擎返回的工件测试 True for .is_derived(). 这看起来像是导致 java 发射器忽略了包目录结构，但我想不出为什么。也许我需要为模板创建一个完整的构建器，停止使用Command，并覆盖默认的.is_derived(). 否则我可以创建一个新的 Java 构建器（基于提供的构建器），而无需对发射器进行此检查。