You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

There a couple ways to adapt ASP to SCons:

  • Make it into a new kind of "override" container
  • Make it a full-fledged container, just like ST and GR.

Override

ASP is similar in all respects to containers ScienceTools, GlastRelease and CHS with one notable exception: it depends on ScienceTools, a full-fledged container, more or less as if it were an external library. When building or running ASP, one must have access to ScienceTools installed files (includes, libraries, python scripts). This is just the way an override directory behaves. The base installation is (or should be) read-only and packages in the override directory may access any of the installed products from the base directory, as well as files installed under the override directory.

In the "normal" use of override, all or most of the override packages are developer versions of packages which already exist in the base directory, but that's not a requirement. In the case of the ASP override directory there would be no packages in common.

So far we know of one detail in the way override directories are treated which doesn't have quite the right behavior for the ASP situation, but there is a simple way to extend the existing behavior to suit the new situation as well as the old. There may be other small glitches; we don't expect anything major.

What is where

The files comprising the SCons machinery are of different types and reside in different places:

  1. package-specific For each package there must be a file called SConscript. For packages building libraries there must also be a file _pkgName_Lib.py. Both are in the package root directory
  2. global, container-specific The file package.scons and the file externals.scons, kept in the top-level directory of the container
  3. global, generic These files are identical for all containers. Only a single copy is kept in CVS (under SConsFiles). This category includes the files SConstruct, processExternals.scons, allExternals.scons and several tools in site_scons/site_tools

Up till now, in the case where there is an override directory, all the global files come from the base, but if the override directory is container-like it might need its own copy of the category 2 files. ASP needs its own package.scons (which should override the ScienceTools one) but, as currently constituted, does not need its own externals.scons.

Modified ASP

CVS organization depends upon the approach chosen.

CVS organization (override)

Make an ASP-scons container package containing

  • an ASP-specific package.scons file
  • src directory with mainpage.h
  • symbolic links to all code packages belonging to ASP (AspHealPix, AspLauncher, etc.) but no link to AspPolicy.

The job AspPolicy does will be handled some other way, perhaps involving adding code to package.scons or inventing a new top-level file.

CVS organization (complete container)

Make an ASP-scons container package containing

  • package.scons
  • externals.scons (must at a minimum reference all externals used by ScienceTools packages)
  • symbolic links to files in category 3 above (SConstruct, allExternals.scons, site_scons/site_tools/) as is the case for other containers
  • symbolic links to all code packages specific to ASP and any used from ScienceTools

To-do

The steps are the same in either case, but details of #1 and #4 depend on approach chosen:

  1. Implement appropriate CVS organization
  2. Add SConscript files to all ASP packages
  3. Add xxxLib.py files to all ASP packages building libraries
  4. Design and implement SCons code equivalent to AspPolicy
  • No labels