Dependencies SCON对编译时生成的文件的依赖性

Dependencies SCON对编译时生成的文件的依赖性,dependencies,code-generation,scons,Dependencies,Code Generation,Scons,我正在尝试设置SCON,以跟踪生成过程中自动生成的文件的依赖关系,并正确处理多线程生成 我正在构建的项目是一个CIM提供程序,由定义数据结构的MOF文件、来自MOF文件的自动生成源文件和头文件以及引用自动生成文件的手写源文件和头文件组成。为了使构建成功,在编译任何手写文件之前,必须运行自动生成步骤直到完成,否则手写文件所依赖的标题将不存在,并且将失败。自动生成步骤创建的.cpp文件也必须添加到源代码列表中,并在最终生成中编译 当运行单线程构建时,一切正常,因为自动生成步骤总是在编译步骤之前完成,

我正在尝试设置SCON,以跟踪生成过程中自动生成的文件的依赖关系,并正确处理多线程生成

我正在构建的项目是一个CIM提供程序,由定义数据结构的MOF文件、来自MOF文件的自动生成源文件和头文件以及引用自动生成文件的手写源文件和头文件组成。为了使构建成功,在编译任何手写文件之前,必须运行自动生成步骤直到完成,否则手写文件所依赖的标题将不存在,并且将失败。自动生成步骤创建的.cpp文件也必须添加到源代码列表中,并在最终生成中编译

当运行单线程构建时,一切正常,因为自动生成步骤总是在编译步骤之前完成,所以生成的头都已就位。但是,当运行构建多线程时,它会尝试在自动生成步骤完成之前编译手写文件,构建失败。我已经指定了一个显式依赖项,但SCons没有遵循它

这是我的SConscript文件的相关部分,我从cim_targets[]中删除了各个文件名,因为列表很长,但总而言之,cim_targets[]是自动生成步骤的目标输出文件列表,provider_sources[]是自动生成步骤完成后返回的源列表,sources[]是手写源文件的列表,GenProvider()是一个外部定义的命令生成器,用于执行自动生成步骤,SharedLibrary()是一个外部定义的生成器,它执行听起来像的操作,使用带有一些扩展名的SCons库生成器

# Define directory paths for the CIM schema
cim_dir = 'cim-schema-2.26.0'

var_smis_dir   = Dir('.').abspath # src/lib/XXX in variant

cim_sources = [
    Glob(os.path.join(cim_dir, '*qualifiers*.mof')),
    Glob(os.path.join(cim_dir, 'Core')     + '/CIM_*.mof'),
    Glob(os.path.join(cim_dir, 'Device')   + '/CIM_*.mof'),
    Glob(os.path.join(cim_dir, 'Event')    + '/CIM_*.mof'),
    Glob(os.path.join(cim_dir, 'XXXXXX')   + '/XXX_*.mof'),
    Glob(os.path.join(cim_dir, 'Interop')  + '/CIM_*.mof'),
    Glob(os.path.join(cim_dir, 'Physical') + '/CIM_*.mof'),
    Glob(os.path.join(cim_dir, 'System')   + '/CIM_*.mof'),
]

cim_sources_flat = []
for cim in cim_sources:
    for src in cim:
        cim_sources_flat.append(src)

cim_targets = [
    ......
]

sources = [
    'driver.cpp',
    'device.cpp',
    'cim_static_data.cpp',
    'module.cpp',
    'diag_log.cpp',
    'profile_element.cpp',
]

staticlibs = [
    ......
    ]


dynamiclibs = [
    .....
    ]

var_cim_sources = this_env.Install(var_smis_dir, cim_sources_flat)

cim_mof = 'cimv226.mof'

cim_linux_mof = os.path.join(cim_dir, 'cimv226-gen-flat.mof')

var_cim_sources.extend(this_env.Command(cim_mof, cim_linux_mof, Copy('$TARGET', '$SOURCE')))

# first generate the provider infrastructure using cimple
provider_sources = this_env.GenProvider(cim_targets, var_cim_sources, name, var_smis_dir)

# make sure these files don't build until AFTER the provider files have been created
this_env.Depends(sources, provider_sources)

sources_full = provider_sources + sources

# now we can compile the provider
this_env.SharedLibrary(libname, source=sources_full, staticlibs=staticlibs, dynamiclibs=dynamiclibs, installpath=install_dir)

我尝试设置一个显式依赖项,以便在创建所有生成的源之前(此_env.Depends(sources,provider_sources))手写源不会编译,但在运行多线程时,SCons忽略此依赖项,并尝试在自动生成步骤完成之前编译手写文件。

您是否尝试使用此处定义的SideEffect()函数:


我不确定它是否完全是为您的需要而创建的,但可能会有所帮助。

我可以通过将生成的文件设置为
命令的目标来解决这个问题。例如,假设您有一个文件
foo.c

#include <stdio.h>
#include "foo.h"
int main() {}
生成输出如下所示:

import time

def build_foo(target, source, env):
    print("Generating foo source files")
    time.sleep(5)
    with open("foo.h", "w") as f:
        f.write("")
    # Generate bar.so, which we need later for X, blah blah blah
    print("Done generating")

env = Environment()
env.Command(['foo.h', 'bar.so'], 'foo.in', build_foo)
env.Program('foo', 'foo.c')
$ scons -Q -j4
build_foo(["foo.h", "foo.so"], ["foo.in"])
Generating foo source files
Done generating
gcc -o foo.o -c foo.c
gcc -o foo foo.o
$ scons -Q -j4
gcc -o foo.o -c foo.c
build_foo(["foo.so"], ["foo.in"])
Generating foo source files
foo.c:2:10: fatal error: foo.h: No such file or directory
 #include "foo.h"
          ^~~~~~~
compilation terminated.
scons: *** [foo.o] Error 1
Done generating
如果省略
foo.h
作为目标(即
env.Command(['bar.so'],'foo.in',build\u foo)
,则生成输出如下所示:

import time

def build_foo(target, source, env):
    print("Generating foo source files")
    time.sleep(5)
    with open("foo.h", "w") as f:
        f.write("")
    # Generate bar.so, which we need later for X, blah blah blah
    print("Done generating")

env = Environment()
env.Command(['foo.h', 'bar.so'], 'foo.in', build_foo)
env.Program('foo', 'foo.c')
$ scons -Q -j4
build_foo(["foo.h", "foo.so"], ["foo.in"])
Generating foo source files
Done generating
gcc -o foo.o -c foo.c
gcc -o foo foo.o
$ scons -Q -j4
gcc -o foo.o -c foo.c
build_foo(["foo.so"], ["foo.in"])
Generating foo source files
foo.c:2:10: fatal error: foo.h: No such file or directory
 #include "foo.h"
          ^~~~~~~
compilation terminated.
scons: *** [foo.o] Error 1
Done generating

自动生成步骤确实创建了一个清单文件,因此我尝试将其用作副作用目标:但不幸的是,问题仍然存在,感谢您的建议,尽管您在python操作函数中添加了睡眠?@bdbaddog这是为了说明目的-证明SCON在生成
foo
之前会等待,即使通过
 -j4
。这是为了模拟一个需要很长时间的生成步骤。为什么要进行向下投票?因为您不必做任何特殊的工作。如果生成器/命令指定了所有目标和源。并且任何适用的扫描仪都是正确的,并且提供了正确的搜索路径(例如CPPPATH),那么它应该可以正常工作。。@bdbaddog-你在说什么?很明显,你不需要将头文件列为构建目标-你不需要用CMake做这件事。CMake你可以说你的目标依赖于另一个目标,而不需要显式列出任何头文件。很明显,这对你的普通scons用户来说并不明显。因此,这个qu的存在estion有11个向上投票和4个收藏夹。也就是说,不清楚为什么
dependens()
Requires()
以及所有其他SCON API无法阻止SCON并行构建这两个目标,但将头文件列为目标会成功地使SCON序列化依赖顺序。只要您的GenProvider()准确列出其输出文件(目标),并将任何头文件生成到CPPPATH上列出的路径中,然后SCON将不会编译包含这些文件的任何源文件,直到生成这些文件。