allow multiple config.h files in the same installation directory

• Key: STDCXX-336
• Type: Improvement
• Status: Open
• Priority: Critical
• Assignee: Martin Sebor
• Reporter: Andrew Black
• Component/s: Configuration
• Affects Version/s: 4.1.2, 4.1.3, 4.1.4, 4.2.0
• Fix Version/s: 4.3.0

Description

A useful enhancement could be the ability to install multiple versions of the standard library into the same location. While there is nothing in the makefiles that would prevent such an installation, a problem arises with the config.h file in the include sub directory of the install directory. Only one config.h file can reside in this location at a time, and different versions (such as those generated when characterizations are run with different compilers) may differ.

One problem that needs to be considered in implementing (or deciding not to implement) this request is the situation where a config.h file hasn't been generated for a particular os/compiler/buildtype/buildtag.
Another problem to consider is when you have the same os/buildtype/buildtag, but different compilers, and one or both compilers support features that the other doesn't.

Comments

[Martin Sebor]

This is important if we want to allow multiple configurations of the same library to coexist in the same directory as users of the Rogue Wave implementation are accustomed to doing. Bumped up priority to Critical.

[Martin Sebor]

Affects all prior versions (4.1.4 only with stdcxx build infrastructure).

[Martin Sebor]

Due to the lack of time this is not going to happen for 4.2.0. Rescheduled for 4.2.1.

[Martin Sebor]

Not sure renaming the generated $BUILDDIR/include/config.h to include the name (and possibly version) of the compiler along with the build type would be a forward compatible change...

[Martin Sebor]

In addition to the config header this issue involves also storing libraries configured for two or more compilers under the same directory (although most likely not in the same directory since their names would conflict and encoding the name of the compiler or its version in the name of the library binary would cause a binary incompatibility).

A possible solution to the config header problem that I discussed with Travis last week is to encode the name (and possibly version) of the OS and compiler in the name of the generated config header and provide a configuration macro (e.g., _RWSTD_CONFIG) for the user to set to a value identifying this combination. E.g., the name of a config header generated for an 12d build with gcc 3.4.2 on Linux could be config-gcc-3.4.2-linux-12d.h and the value of the _RWSTD_CONFIG macro to select this configuration would be gcc-3.4.2-linux-12d.

A solution to the library problem is to create a subdirectory for each distinct configuration (compiler, OS, and buildtype) under $PREFIX/lib and store libraries there. Users would have to append the name for the subdirectory appropriate for each configuration to their -L$PREFIX option. To continue with the gcc/Linux example above, the install target would create a $PREFIX/lib/gcc-3.4.2-linux-12d subdirectory and store the library (named libstd.so) there. Users would then need to specify -L$PREFIX/lib/gcc-3.4.2-linux-12d -lstd on the link line. For compatibility with the current setup where the buildtype is (or may be) encoded in the library name (libstd12d in our case) the install target could create a link pointing to the suffix-less name (i.e., libstd12d.so -> libstd.so).

[Martin Sebor]

All of this is far too involved for a maintenance release. Rescheduled for 4.3.