[Dune] [Dune-Commit] dune-common r6651 - branches/cmake/cmake/modules

[Christian Engwer]

Hi Bard,

I have to disagree.

> On the contrary--the intended effect of CXX is to allow the user to
> freely inject another toolchain into the build--assuming it is able to
> build the project in the first place, that is.  For instance, I have a
> pair of configurations that modify only the CXX (one is "g++-4.1", the
> other is plain "g++" that just happens to correspond to GCC 4.4 on this
> particular system).  One might similarly envision a user's desire to
> build 32-bit binaries by specifying CXX="g++ -m32".  Moreover, I very
> much think that the choice of debug versus release should be made
> through the CXXFLAGS--typically at configure time.  A build system has
> no business overriding a configuration's choice of debug level--that is
> entirely up to the builder.

Your assuption only holds, if I substitute with a _compatible_
toolchain. That is exactly the point.

Just a few examples:
- there is no defined way of name-mangling, thus the two compilers
  might generate totally incompatible object files
- one compiler supports tr1, the other doesn't. The buildsystem will
  set the appropriate HAVE_* entries and the code fill fail with the
  other compiler (e.g. tr1 support in g++-4.* and g++-3.3)
- newer compiler migth come with out-of-the box c++-11 support, while
  you substitution compiler doesn't
  
In the case of you example of "g++ -m32" it becomes obvious. This
feature won't work without rebuilding and the user will not be
surprised, even if he has to reconfigure, because several libs are not
found where they were expected.

I agree that it is safer not to alter any make variables, but I still
think the most common case is >>make CXXFLAGS="..."<< Furthermore it is
explicitly supported by the autotools.

Christian