我正在努力研究最后的逻辑,以使我们的 Ada 构建器按预期与variantdir一起工作。该问题是由于不灵活的工具 gnatbind
和 gnatlink
不允许将 Binder 文件放置在当前目录以外的目录中而引起的。这给我留下了两个选择:
- 让 gnatbind 将 Binder 文件写入 topdir,然后让 gnatlink 从那里选择它。然而,如果我们想要允许针对我们想要的不同架构和编译器版本进行模拟构建,这可能会导致竞争条件。
修改对 gnatbind 和 gnatlink 的调用,以暂时转到构建目录,在我们的示例中为
build/$ARCH/src-path
。我成功修复了gnatbind
步骤,因为这是使用 Ada 构建器中的env.Execute
显式调用的。为了尝试修复链接步骤,我使用修改了程序环境env["LINKCOM"] = SCons.Action.Action(ada_linkcom)
其中 ada_linkcom
定义为
def ada_linkcom(source, target,env ):
....
return ret
其中 ret
是描述 shell 中应执行的操作的字符串。我需要这是一个函数,它包含一些复杂的逻辑,用于将路径从相对于顶级的路径转换为仅包含它们的基本名称。
但是,此操作失败,并在函数 do_execute
的第 347 行的 scons-2.3.1/SCons/Executor.py
中出现错误。是否不允许 env["LINKCOM"]
成为具有 ada_linkcom 签名的函数?
最佳答案
不,不是。您似乎认为 'env["LINKCOM"]' 是实际调用/执行最终构建命令的内容,但这并不完全正确。相反,像 LINKCOM 这样的环境变量会被 Executor/Builder 为每个指定的 Action 扩展,然后被执行。
您可以将 Python 函数用作操作,还可以使用所谓的“生成器”来动态创建操作字符串。但你必须将此Action分配给一个Builder,并且不能直接将其设置为环境变量。
另请参阅用户指南 ( http://www.scons.org/doc/production/HTML/scons-user.html ),特别是第 18.4 节“执行 Python 函数的构建器”。我们编写构建器和工具的基本指南也可能会有所帮助:http://www.scons.org/wiki/ToolsForFools
关于builder - 尝试使 SCons Ada Builder 与 VariantDir 一起工作,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23761683/