algrebe
algrebe

Reputation: 1651

scons sequential commands not as expected in dependency tree

I'm running an SConscript which is called by a SConstruct which does nothing but set the environment and Export('env'). The SConscript is supposed to iterate over files with filenames like mod_abc.c and for each of these files - First create an xml dir, generate a structdoc, create a file mod_abc_post.c and then an object file and a '.so' file. After that it should remove the xml file and restart the process for the next mod_*.c file. Heres the script:

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')

Ive taken care that xml_dir target gets a particular name as that xml command should be run only for that mod_name. The problem is that the dependency tree is not as expected. I expect a tree like this for each of the files

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

But what I get by doing scons --tree=ALL is for example just one of them mod_serialize_example.c is:

The dont come in order, there are things in the middle as well which are for other mod_*.c files.

[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

What i would expect for mod_serialize_example.c is

+-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

However, I see this and a lot more than required. (also the above one was just manually done to give an idea of the process, pardon the indentation with the + and | )
Shouldn't they all bunch up together ? (As shown in the expected tree, and repeat like a loop for the different filenames).
Also, Im just getting started with scons and any help in making this design cleaner would be helpful.
1. I would like to know how to get the expected tree
2. How can I make this script take a module name and run the for loop code only on that.
example: scons mod_abc.c should create the .so file only for that. As of now, this doesnt produce anything if i do that.

Upvotes: 2

Views: 450

Answers (1)

Tom Tanner
Tom Tanner

Reputation: 9354

Why would you expect a tree like that? There's no (explicit or implicit) dependency of anything else on your shared library for instance. So it will go as one of the targets at the top of the graph.

Upvotes: 1

Related Questions