Since optimized builds on Linux are possible, run significantly faster than unoptimized, and we are (and probably will be, from here on out) in a situation where large runs are routinely requested, the current automated-build setting, building non-optimized only, is not ideal. However, there is a need for the ability to use a debugger on Linux, both for development and in order to track down bugs in production builds.
It would be nice to have unoptimized and unoptimized builds of everything readily available, but, given the way we actually use the builds, that seems unnecessary and could put a strain on resources like disk space. The three classes of builds (tagged, HEAD, and LATEST) serve different functions and are built with different frequency. External libraries form a fourth class. Without any noticeable loss of functionality, I think we could just
The default for manual builds (initiated by a person rather than the Release Manager) should continue to be unoptimized.
Tagged releases and external library releases are relatively infrequent, so this procedure wouldn't use much more disk space than we're using currently. It's unlikely that anyone would want to make long runs with LATEST, so no harm is done by omitting optimized LATEST builds. However, in recent times GlastRelease LATEST almost always does build without error; ScienceTools LATEST is ok more often than not. The availability of unoptimized LATEST and unoptimized tagged builds should provide adequate support for debugging and development.
Do we really need both optimized and unoptimized builds of tagged releases and external libraries? I think so. Certainly we want optimized builds available so that we reap their advantages for production runs. However, if we suspect any problem with a release, we will want to apply all available tools without delay. Also, having unoptimized, debug versions of stable releases provides a point of comparison with code under development, just in case there is no trustworthy LATEST available. These arguments apply equally well to external libraries.
One critical element omitted above is the time and effort involved in implementing such a scheme. Possible sticking points include
I think we must have the two sets of external libraries. They are too difficult (in some cases, at least) for individual users to have to build on their own, but also essential to have in both forms. However, we don't build new versions very often. We presumably already have optimized and non-optimized builds for the current recommended set, so, for the time being, no work on anyone's part should be required for this. [Slight amendment added in April, 2004: we probably only need optimized builds of libraries heavily used during event processing, such as Geant and Gaudi. Xerces is used almost exclusively during initialization; whether or not an optimized build of it is used shouldn't make much difference.]
We could make do temporarily without unoptimized builds of our own code if and only if there is a straightforward procedure which can be invoked by anyone to create an unoptimized build. If built on SLAC public machines, the procedure should also by default put the build in group space.
* Debug and Optimize: The debug and optimize compiler flags are independent. It is possible to use a source-code debugger even in code which has been optimized as long as debug symbols are there, but much more difficult and subject to misinterpretation. However, at least it is possible to get a meaningful traceback. optimized in the above discussion therefore means optimized, debug symbols . unoptimized of course implies debug. Back to reference
J. Bogart
Original version: 27-Oct-2003
Last modified: