...
The closest analog to cmt show uses in SCons is probably the LIBS contruction environment variable, used to construct the link command for a particular target. It has a list of all libraries (by name; does not include path information) needed in the link. In principal there could be a different LIBS variable for every target, but usually all or most applications in a single package will use the same construction environment (hence have the same value for LIBS). The LIBS variable for the primary shareable library is necessarily different since it doesn't include a reference to itself. LIBS includes references to external libraries as well as locally-built ones, so it will be necessary to discover which names refer to externals and exclude them from further processing. Done as 4/2
In order to make it easy to refer to "foreign" project files I will probably change the scheme I have now (in which project and solution files for a package are kept in a special directory under the package root) to one where project and solution files are installed in a top-level variant directory, as is the case with libraries, include files, etc. Done as of 4/2
Support for generating project and solution files is currently split between our locally-written tool, registerObjects.py, and SCons-supplied (but locally enhanced) msvs. py. registerObjects does more than just generate project and solution files, but it is beginning to look somewhat top-heavy (also the current call-interface for registerObjects isn't quite adequate since there is no place for per-target construction environment) so I plan to split off the project/solution file support to a separate module, say called studioFiles makeStudio. Since interface needs to change, made a replacement for registerObjects (working name is registerStuff) with the new interface. It handles non-Windows-specific registration, then invokes makeStudio. Done as of 4/2.
For each target belonging to the package, studioFiles makeStudio will invoke msvs.MSVSProject() to make a project file. This is already being handled by the current version of registerObjects. The only change will be to install the project file in the new top-level variant directory. Then studioFiles makeStudio will call msvs.MSVSSolution but instead of just passing a list of project files, as is currently done, it will also have to pass in the associated pruned (external libraries excluded) LIBS variables. Made mods to externals.scons to make set of external library names available as a set via construction variable. makeStudio uses this to compute set of non-external libraries required for each project. Done as of 4/2
msvs.MSVSSolution() will need considerable work to get the dependencies into the solution file and to do it efficiently. The latter will involve a suitable design of data structures to store derived information from previously-handled values for LIBS in a quickly retrievable and usable form.
...