Re: compiler flag issues

2019-12-01 Thread James Lowe
Hello,

On Sat, 30 Nov 2019 12:00:19 -0500, Dan Eble  wrote:

> On Nov 28, 2019, at 03:13, Werner LEMBERG  wrote:
> > 
> > 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.

Well not quite 'for ever' (since 2011)

https://lists.gnu.org/archive/html/lilypond-devel/2011-09/msg00673.html

Also see: 

https://sourceforge.net/p/testlilyissues/issues/1905/

and

https://codereview.appspot.com/4974075/#msg12

There;s some old discussion in the dev archives if you search just for 'disable 
optimising' you'll get some hits - it's all beyond me though.

Regards

James


Re: compiler flag issues

2019-11-30 Thread 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 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



Re: compiler flag issues

2019-11-30 Thread Dan Eble
On Nov 28, 2019, at 03:13, Werner LEMBERG  wrote:
> 
> 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.

> 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 sites.
—
Dan




compiler flag issues

2019-11-28 Thread Werner LEMBERG


Most developers expect that you can easily adjust C++ compiler flags
in a GNU package using CXXFLAGS.  With LilyPond, however, this is
quite problematic.  Reason is that it internally uses the following
variables to compute the final list of compiler flags (see files
`c++-vars.make` and `aclocal.m4`):

  OPTIMIZE = 
  SANITIZE = 

  CXXFLAGS = $CXXFLAGS \
 $OPTIMIZE \
 $SANITIZE

  EXTRA_CXXFLAGS = -W -Wall -Wconversion

  ALL_CXXPPFLAGS = $(CPPFLAGS) \
   $(CONFIG_CPPFLAGS) \
   $(DEFINES) \
   $(INCLUDES:%=-I%)

  ALL_CXXFLAGS = $(CXXFLAGS) \
 $(ALL_CXXPPFLAGS) \
 $($(PACKAGE)_CXXFLAGS) \
 $(CONFIG_CXXFLAGS) \
 $(MODULE_CXXFLAGS) \
 $(EXTRA_CXXFLAGS)

As an example, the quite frequent idiom to disable optimization with

  ./configure CXXFLAGS="-O0"

fails because $OPTIMIZE overrides this.  Similarly, it is not possible
to disable a warning like

  ./configure CXXFLAGS="-Wno-sign-conversion

since it gets overridden by the `-Wall -W -Wconversion` options in
$EXTRA_CXXFLAGS.  Instead, you have to say

  make EXTRA_CXXFLAGS="-W -Wall -Wconversion -Wno-sign-conversion"

(completely bypassing the configuring step) to disable sign conversion
warnings.

This is very, very non-standard and completely undocumented.

Any idea how this could be improved?


Werner