GlastRelease Conversion to SCons: Status and Issues
Package Conversion
Five packages remain to be converted to use newer tools (registerTargets rather than registerObjects). "Conversion" as used here also includes a re-examination of dependencies and other aspects of the package SConscripts generated by Emmanuel for a much older version of GlastRelease. A few issues need to be addressed in order to complete this work:
- GlastClassify builds a static library and a guadi component which includes everything from the static. Requires some fancy footwork in one or both of the package SConscript and GlastClassifyLib.py.
- calibGenTkr depends on calibTkrUtil. The latter defines a macro for its source files which is then used in calibGenTkr. It's neither typical nor desirable to import source (.cxx) from one package into another. I'd like to find a way to avoid it.
- OnboardFilter will not build with current (SCons-specific) organization of the obf external.
Gaudi Component Libraries
Windows builds
On Windows Gaudi component libraries are (that is, should be) built differently from non-Gaudi dlls. For the non-Gaudi dlls only the link command must be preceded by a step to generate exported symbols. It is neither necessary nor desirable for Gaudi component libraries. Current SCons code does not provide a way to make a distinction; the symbol generation step will happen in all cases. Work required includes
- modifications to processExternals to support both kinds of builds
- modifications to registerTargets, makeStudio and our private msvs to provide a way to ask for the appropriate kind of build and to get necessary information into project files
- trivial modifications to SConscript files for those packages building Gaudi component libraries
Dependencies
Since Gaudi component libraries may be loaded dynamically, test programs in other packages may require libraries at run time which are not needed at link time. Whether or not they are required at run time can, for example, be a function of job options. Should such dependencies be known to SCons? I've discussed this with Tracy and Leon and believe the following satisfies everyone's needs:
- do not make such a dependence on component libraries for most packages.
- Gleam will depend on all the component libraries (as well as all other package libraries). As a side-effect, the created Gleam solution file will reference all library project files.
Job options
The current arrangement causes most programs dependent on job options to fail because the files can't be found. They need to be installed: that is, copied to a top-level directory as is now done for xml files, include files, data files, python files, etc. Because there is a lot of duplication of names, there should be per-package subdirectories as is the case for include. Work required to implement this includes
- modifications to registerTargets and other tools to recognize the new category of installable files (easy)
- modifications to package SConscripts needing to install such files (easy but tedious because of the number of packages involved)
- modifications to Pipeline code and perhaps job options files so all job options files can be located at run time
- (maybe) modifications to TestMain to take care of standard simple test programs
Most likely the above will not cover everything. Package maintainers would be responsible for the rest.
External Libraries
Certain external libraries are not yet available for vc90.