Re: compiler flag issues

[Werner LEMBERG]

>> This is very, very non-standard and completely undocumented.
> 
> Not completely undocumented.  The CG has said to run configure with
> --disable-optimising for as long as I can remember.

I don't mean this option but the fact that CXXFLAGS as set by the user
gets almost completely overwritten.

>> Any idea how this could be improved?
> 
> A good start would be to refer us to the standard.  For some of us,
> LilyPond is our primary or only exposure to autoconf, which
> naturally leads to the when-in-Rome approach to maintenance.  My web
> searches on CXXFLAGS have led to the manual for automake, which I'm
> not sure is used here, and various disputed answers about autoconf
> on community Q&A sites.

It's rather the section 'Preset Output Variables' in the autoconf
manual.  There you can find the following comment to the sibling
option `CFLAGS`, which also holds for `CXXFLAGS`:

     Sometimes package developers are tempted to set user variables
     such as `CFLAGS' because it appears to make their job easier.
     However, the package itself should never set a user variable,
     particularly not to include switches that are required for proper
     compilation of the package.  Since these variables are documented
     as being for the package builder, that person rightfully expects
     to be able to override any of these variables at build time.  If
     the package developer needs to add switches without interfering
     with the user, the proper way to do that is to introduce an
     additional variable.  Automake makes this easy by introducing
     `AM_CFLAGS' (*note Flag Variables Ordering: (automake)Flag
     Variables Ordering.), but the concept is the same even if
     Automake is not used.

The minimum thing we should do is (a) to document EXTRA_CXXFLAGS both
in the manual and in the `--help` text of the `configure` script, and
(b) to make it possible to set it at configuring time.


  Werner