Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

A partial to-do list

  1. Environment setter-upper file might need a little more work. For example, it seems that swig executable is not in path.
  1. Project files seem to want to rebuild everything all the time. For example, rebuilding a facilities test program from Studio compiles not just program-specific source, but also those files in the facilities library which the program depends on, even though the library was just built.

Already-done list

  1. Figure out what needs to be in a library project file to get Studio to copy the library to the SCons variant lib directory (same place the library gets installed when built by SCons). Done 3/10
  2. Currently only .cxx files are added to projects. Need .h, possibly also xml, python, etc. Done 3/11 for includes, xml, python and pfiles. These files are already known if there is a suitable call to registerObjects in the package SConscript file.
  3. The .cxx files in the project are specified using an absolute file path. This allows Studio to find the files, but means that the project files are not portable. They must be built where used. Should make a special SCons target for an installation which only regenerates all project and solution files.
    Wiki Markup
    _\[3/11 update: Probably this will entail enhancements in our SCons machinery to make it easy to identify various targets and a feature in GoGui making it easy to request build of a specific target.\]_
     Done 3/20
  4. Don't know how to make a solution file referencing all the projects in a package. When I try the obvious thing from within SCons, invoking MSVSSolution( ), the resulting file uses paths to the SCons build area rather than real destination of the file. The ones in the build area are not (and are not intended to be) usable as project files. When I tried adding a second project to a solution file from within Studio it balked. Done 3/20 solution file now uses correct absolute paths to reference project files. Done 3/23 solution file is installed in a reasonable place instead of languishing in SCons build directory.
  5. Solutions files created by SCons need to a) include references to project files for all libraries used, not just the ones in the current package and b) keep track of dependencies among the projects so that build order is correct. Done 4/10
  6. Add custom tool for swig to project files when library is a wrapper and other special handling needed in project files for wrapper libraries Done 4/21
  7. Add custom tool for rootcint to project files when library needs to be dynamically loadable from ROOT.  Done 5/8
  8. Get SCons to create a usable environment-setter-upper, probably a .bat file that can be run before invoking devenv. Partially done as of 3/13.  _setup.bat fixes up the PATH variable but doesn't yet handle other variables. As of 3/20 also defines INST_DIR. Still need to add definition for ROOTSYS, add to PYTHONPATH and (the tough one) deal with pfiles. As of 4/21 added stuff needed for swig and to determine which library dependencies are externals and which are not. Done 6/16 using a two-part method: default build creates _setup.vbs which, when run, writes _setup.bat. The latter has hard-coded paths so should only be created by the end-user. (looks like Swig set-up got inadvertantly left out, though).

Solution files - a plan
Anchor
solution_plan
solution_plan

...

msvs.MSVSSolution() will need considerable work to get the dependencies into the solution file andto 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.

Already-done list

...

Wiki Markup
_\[3/11 update: Probably this will entail enhancements in our SCons machinery to make it easy to identify various targets and a feature in GoGui making it easy to request build of a specific target.\]_

...

. Done 4/10 (Efficiently enough for now, anyway).