...
For Pass8 GlastRelease will need access to all the irfs packages. Rather than adding these packages in the usual way, the proposal has been made to put them in their own external and put all the packages they depend on (facilities, astro, etc.) in another external. ST and GR would then link to both of these externals. GRBAnalysis could also.
Alternative #1
Put all of the above in a single external. ST, GR and GRBAnalysis all need all of these things.
...
Con: irfs could be much more volatile than the other packages
Alternative #2
Put all of the above plus other common packages (celestialSources, flux, xmlBase) into a single new external.
...
irfs will be pared down slightly for the new external in order to reduce the number of other packages required. In particular irfs/irfLoader and irfs/handoff_response will be modified to build only the library. Or irfs/handoff_response could be eliminated entirely since it's not needed by GR.
Sandbox Experience
To start I'm going with alternative #1: single internal external including irfs and minimal other packages to make it self-contained: facilities, tip, astro, st_stream, st_facilities and irfs/irfLoader will be modified to build only the libraryembed_python. The new internal is provisionally called "CommonExt". After making changes to irfs/irfLoader and irfs/handoff-response as described above I built it with SCons, using option --variant=NONE to produce a build suitable for export.
A Snag
The facilities package does some special things at build time which impact the entire container. It creates a file config.h in the facilities/src directory and the file src/commonUtilities.cxx has a #include for this file. The contents of config.h is a macro defining the set of packages in the container, something commonUtilities needs to know in order to properly define environment variables at run-time so that, for example, job options files and xml files may be found. Each container must have its own compilation of commonUtilities.