Greetings all.

Attached is a different solution to (and Changelog for) the core issue 
observed, that of the incorrect RPATH value for the test suite on AIX 
5.3.  Rather than defining directory specific LDFLAGS variables, this 
patch defines a new variable (RPATH), and appends it to the LDFLAGS 
variable in each directory's makefile, along with the relevant directory 
path.

Martin and I spent probably an hour or so this morning discussing 
different ways to generate the proposed sectional makefile.in setup. 
The conclusion that was reached was that generating these files would be 
an extremely verbose process.  In addition, the fatal flaw is the 
inability to remove or combine flags.  An example is if a pair of flags 
defined in different files (such as makefile.release.in and 
makefile.static.in) are mutually exclusive.  Another example is the MSVC 
runtime library options, which vary on two or three build mode options.

The basic layout of the sectional makefile would likely have been as 
follows.
The 'core' makefile.in contains variables that are used in all builds 
with a given compiler on a given platform.  This is mostly the same as 
the existing makefile.in.
In addition to this makefiles, a generated makefile would exist for each 
  build type attribute, and would be named like makefile.attribute.in. 
The attributes are debug/optimized, archive/shared, 
nothread/posix/solaris/dec, and narrow/wide.  These variables would 
contain the (narrow) set of variables which do vary.  These variables 
would be SUFFIX (only for archive/shared), CXXFLAGS, CPPFLAGS, LDFLAGS, 
  and ARFLAGS.

Within the .config files, these changing variables would be named like 
VARIABLE.mode (ie: CXXFLAGS.debug and LDFLAGS.shared, taking the place 
of the existing DEBUG_CXXFLAGS and SHARED_LDFLAGS variables respectively).

A similar set of files would exist in each major subdirectory.  The 
variables within the .config files would be named like VARIABLE.dir (for 
the makefile.in in each directory) and VARIABLE.dir.mode (for the 
makefile.mode.in in each directory).

Another concept that was discussed was the possibility of creating a 
compiler driver.  This driver would handle translating a set of gcc 
style compiler switches into switches understood by each compiler, along 
with such things as template repository locations and rpath control 
switches.

--Andrew Black