Re: [Boost-users] Version Mgmt classes/algorithms

From: Noel Yap (noel.yap_at_[hidden])
Date: 2006-01-27 11:45:23

On 1/27/06, Rob Lemley <rclemley_at_[hidden]> wrote:
> Noel Yap wrote:
> > On 1/26/06, Rich Johnson <rjohnson_at_[hidden]> wrote:
> > 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".

Right.  I tend not to consider this a version management issue, per
se, but more a deployment and configuration issue.  For example, if
components were deployed into directories encoding architecture,
compiler, compiler version, compiler flags, ... then those depending
upon it need to know how to configure themselves so as to use the
right one.  This shouldn't be too difficult since the dependent
components will need to know how they need to be deployed, too. 
Perhaps it's just a matter of semantics and definitions.

BTW, I didn't originate the idea of encoding such things as part of
the directory name; I picked it up from my last place of employment --
just want to be sure I'm not taking credit for something that's not
mine.

Noel