Python scons顺序命令在依赖关系树中不符合预期

我正在运行一个SConscript，它由一个SConstruct调用，该SConstruct只做设置环境和导出（'env'）。SConscript应该迭代文件名为mod_abc.c的文件，并且对于这些文件中的每一个，首先创建一个xml目录，生成一个structdoc，创建一个mod_abc_post.c文件，然后创建一个对象文件和一个“.so”文件。在这之后，它应该删除xml文件并重新启动下一个mod.*.c文件的进程。 下面是脚本：

import os
Import('env')

my_libs = 'jansson'
postc_files = Glob('mod_*_post.c')
all_mods = Glob('mod_*.c')

mods = set(all_mods) - set(postc_files)
mods = list(mods)

env['STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME']=1

xml_cmd_str = '(cat ../Doxyfile.configxml; echo "INPUT=%s";) | doxygen - > xml%s'
structdoc_cmd_str = 'python ../prep_structdoc.py xml mod_config mod_mtx update_mtx serialize_mtx "mod_evt_" > %s'
preprocess_cmd_str = 'python ../preprocess_mod.py xml %s %s > %s'


for mod in mods:
    #create doxy file
    xml_dir = env.Command('xml%s' % mod.name, mod, xml_cmd_str % (mod.name, mod.name))

    mod_name = mod.name[:-2]
    struct_doc = '%s.structdoc' % mod_name

    #using Command instead of os.popen as clean can take care of structdoc
    sdoc = env.Command(struct_doc, xml_dir, structdoc_cmd_str % struct_doc)

    processed_file= '%s_post.c' % mod_name
    pfile = env.Command(processed_file, sdoc, preprocess_cmd_str % (mod_name, struct_doc, processed_file))

    obj_file = env.Object(target='%s.o' % mod_name, source=pfile)

    shared_target = '%s.so' % mod_name
    env.SharedLibrary(target=shared_target, source=obj_file, LIBS=my_libs)

    py_wrapper = env.Command('%s.py' % mod_name, pfile, 'ctypesgen.py %s %s -o %s' % (processed_file, mod.name, '%s.py' % mod_name))

    # remove xml once done
    remove_xml = env.Command('dummy%s' %mod.name, py_wrapper, 'rm -rf xml')

我注意到xml_dir target会获得一个特定的名称，因为xml命令应该只针对该mod_名称运行。问题在于依赖关系树没有达到预期效果。 我希望每个文件都有这样一棵树

-remove xml  
--create py_wrapper  
---create so file  
----create o file  
-----create _post.c file  
------create .structdoc file  
-------create xml directory  

但是我通过执行scons--tree=ALL得到的只是其中一个mod_serialize_示例。c是：

不按顺序排列，中间也有其他的MOD**.C文件。

[Some other things before this]
 +-dummymod_serialize_example.c
  | +-mod_serialize_example.py
  | | +-mod_serialize_example_post.c
  | | | +-mod_serialize_example.structdoc
  | | | | +-xmlmod_serialize_example.c
  | | | | | +-mod_serialize_example.c
  | | | | +-/usr/bin/python
  | | | +-/usr/bin/python
  | | +-/usr/local/bin/ctypesgen.py
  | +-/bin/rm
[Some other things after this]

 +-libmod_serialize_example.so
  | +-mod_serialize_example.o
  | | +-mod_serialize_example_post.c
  | | | +-mod_serialize_example.structdoc
  | | | | +-xmlmod_serialize_example.c
  | | | | | +-mod_serialize_example.c
  | | | | +-/usr/bin/python
  | | | +-/usr/bin/python
  | | +-mod_serialize_example.c
  | | +-/path/to/header files included
  | | +-/usr/bin/gcc
  | +-/usr/bin/gcc
 +-mod_addition.c [ Some other module ]

 +-mod_serialize_example.c
  +-mod_serialize_example.o
  | +-mod_serialize_example_post.c
  | | +-mod_serialize_example.structdoc
  | | | +-xmlmod_serialize_example.c
  | | | | +-mod_serialize_example.c
  | | | +-/usr/bin/python
  | | +-/usr/bin/python
  | +-mod_serialize_example.c
  | +-/path/to/header files included...
  | +-/usr/bin/gcc
 +-mod_serialize_example.py
  | +-mod_serialize_example_post.c
  | | +-mod_serialize_example.structdoc
  | | | +-xmlmod_serialize_example.c
  | | | | +-mod_serialize_example.c
  | | | +-/usr/bin/python
  | | +-/usr/bin/python
  | +-/usr/local/bin/ctypesgen.py
  +-mod_serialize_example.structdoc
  | +-xmlmod_serialize_example.c
  | | +-mod_serialize_example.c
  | +-/usr/bin/python
  +-mod_serialize_example_post.c
  | +-mod_serialize_example.structdoc
  | | +-xmlmod_serialize_example.c
  | | | +-mod_serialize_example.c
  | | +-/usr/bin/python
  | +-/usr/bin/python
  +-pfile
  +-xml
[some other stuff]
 +-xmlmod_serialize_example.c
    +-mod_serialize_example.c

我对mod_serialize_example.c的期望是

+-rm xml
 |+-libmod_serialize_example.so
      | +-mod_serialize_example.o
      | | +-mod_serialize_example_post.c
      | | | +-mod_serialize_example.structdoc
      | | | | +-xmlmod_serialize_example.c
      | | | | | +-mod_serialize_example.c
      | | | | +-/usr/bin/python
      | | | +-/usr/bin/python
      | | +-mod_serialize_example.c
      | | +-/path/to/header files included
      | | +-/usr/bin/gcc
      | +-/usr/bin/gcc

然而，我看到了这一点，而且远远超出了要求。（同样，上面这一步只是手动完成的，目的是让您了解整个过程，请原谅+和|的缩进）
他们不应该聚在一起吗？（如预期的树所示，对不同的文件名像循环一样重复）。
另外，我刚刚开始使用烤饼，任何帮助使这个设计更简洁的方法都会很有帮助。
1.我想知道如何获得期望的树
2.如何使此脚本采用模块名并仅在该模块上运行for循环代码。
示例：scons mod_abc.c应仅为此创建.so文件。

---

到目前为止，如果我这样做，这不会产生任何效果

你为什么期望有一棵这样的树？例如，在您的共享库上没有任何（显式或隐式）依赖关系。因此，它将作为图表顶部的目标之一。

是的，预期的图表将其自身置于顶部。我的问题是，为什么在实际输出中有那么多其他东西显示为依赖项（在实际输出中，这个.so文件是第二部分），顶部的图表显示了.so作为remove xml的依赖项。你也许应该试试--tree=all，prune。默认情况下，如果A依赖于B，B依赖于C，D也依赖于B，那么C将显示两次。此外，这：

remove_xml=env.Command（'dummy%s'%mod.name，py_wrapper，'rm-rf xml'）

不依赖于您的共享库。这取决于其他因素。哦，好吧，当两个事物有相同的依赖性时，依赖性会出现两次。因此，预期的树是错误的，我不应该期望按照编写的代码是这样的。它是否足够离开它，因为它正在工作或重新组织代码来生成预期的树？你需要考虑你想要依赖关系。树没有错——它试图用ascii艺术在二维中显示不一定是二维的东西。但是，正如我所说的，我认为您对树的外观的期望与您的代码不匹配。此外，在我看来，1）您正在删除中间生成目标，这将导致SCON必须重新生成它们；2）这在并行生成中不起作用，因为您正在删除包含不属于当前规则的生成目标的目录