waf: nested projects and _cache.py: not supported?

Question

I am converting a project from autotools to waf with the hope that it can be easily compiled in windows as well.

I am using a super project with two children folders that are 2 projects.

One of them is a library, the other, a program, like this:

1. superproject/wscript
2. superproject/libraryproject/wscript
3. superproject/programproject/wscript

It seems that waf has terrible support for subprojects. I have a wscript in each of these directories.

I recurse from superproject into the 2 other projects, but the _cache.py file is shared for both projects. This has the following side effects (issues):

1. When using the boost tool, I had to use it like this to avoid name collisions:

   # In library project
   cfg.check_boost('boost_program_options', uselib_store='BOOST_LIBRARYPROJECT')
   
   # In program project
   cfg.check_boost('boost_program_options', uselib_store='BOOST_PROGRAMPROJECT')
   

   boost-libs and boost-includes command line options are also lost by default, so I have to set them manually, like this:

   cfg.env.LIBPATH_BOOST_PROGRAMPROJECT = cfg.options.boost_libs
   ...
   

2. The _cache.py file is overwritten by the programproject/wscript, loosing all the configuration for the flags.

Questions:

1. Is there any good way to nest projects and avoid at least issue 2?
2. Is there any reasonable way to avoid both that doesn't require a script and building projects separately?

Answer 1

Configuration file is not written twice.

My mistake was to do this:

cfg.env = ConfigSet()

I wanted a new and clean ConfigSet but doing that in both projects made the first set of flags to be lost.

Since the environment seems to be shared among all project configurations, is it good style to name the variables with custom names? For example, instead of using:

cfg.check_boost('program_options')

Should I use:

cfg.check_boost('program_options', uselib_store='BOOST_MYPROGRAMPROJECT')

1. Is this good style or it's usually done in another way?
2. Can be done in a cleaner way deriving ConfigSets?