Re: compiler flag issues
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
>> 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
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
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