Noel Yap wrote:
On 1/26/06, Rich Johnson
wrote: On Jan 26, 2006, at 11:58 AM, Noel Yap wrote: FWIW, a "compiler compatibility" is probably required when dealing with separately compiled modules.
You're right. I hadn't considered that. I'll add it to my list of caveats. Oh, wait, it just occurred to me that I would take care of this by encoding architecture, compiler, and compiler flags into the installation directory name.
You might also desire to encode the compiler version or at least the ABI version. For example, the ABI can change in between compiler version releases for the GCC collection. Also, the default allocator is a build-time option for GCC's g++ compiler, which can make modules compiled with the same version of the compiler incompatible if the compilers were built with different default allocators, even though the compiler version is the same. This may be beyond the scope of automatic version management, but underscores the need for the version management process to account for "compiler compatibility". Some discussion of c++ ABI and versioning in the c++ std lib which may also be pertinent to versioning in large systems: http://gcc.gnu.org/onlinedocs/libstdc++/abi.html