Re: different CFLAGS for gnulib code?
On 15/01/2021 08:55, Bruno Haible wrote: I always thought that GNU package maintainers want their entire package to be compiled with the same CFLAGS and CPPFLAGS. Would compiling the gnulib part with options for fewer warnings be OK with you? Paul, Pádraig, Jim, Paul, Akim, Simon, all: what's your opinion? Re coreutils we already have different warnings, specifically a subset of warnings are used with gnulib. gnulib is necessarily more general/portable than a particular project, and so could not be as generally stringent in its warnings I think. Also a new project has more flexibility to enable a stricter set from the start, than a mature code base like gnulib. cheers, Pádraig
Re: different CFLAGS for gnulib code?
On 15.01.21 12:11, Paul Eggert wrote: > On 1/15/21 12:55 AM, Bruno Haible wrote: >> Would compiling the gnulib >> part with options for fewer warnings be OK with you? > > Not only is it OK, it's routine. Coreutils, Emacs, etc. do it. > Wget does the same thing as well. I treat gnulib as another library, libraries are not necessarily compiled with the same compiler options.
Re: different CFLAGS for gnulib code?
On Fri, Jan 15, 2021 at 12:55 AM Bruno Haible wrote: > Jeffrey Walton wrote: > > Perhaps it would be a good idea to filter-out the options that you > > don't want present for Gnulib. ... > It is an interesting idea. Leaving the question aside how it is implemented > (through an AC_SUBSTed variable or what else), the main question is: Would > some GNU package maintainers want this? > > I always thought that GNU package maintainers want their entire package to > be compiled with the same CFLAGS and CPPFLAGS. Would compiling the gnulib > part with options for fewer warnings be OK with you? > > Paul, Pádraig, Jim, Paul, Akim, Simon, all: what's your opinion? Yes, I do something like that in every package for which I make releases, these days. There is a separate clause in configure.ac where we arrange to remove troublesome warning options from the global list to form the CFLAGS options used for gnulib proper: AC_SUBST([GNULIB_WARN_CFLAGS]) and sometimes also (e.g., in grep) where we do similar for gnulib tests: AC_SUBST([GNULIB_TEST_WARN_CFLAGS])
Re: different CFLAGS for gnulib code?
fre 2021-01-15 klockan 09:55 +0100 skrev Bruno Haible: > It is an interesting idea. Leaving the question aside how it is > implemented > (through an AC_SUBSTed variable or what else), the main question is: > Would > some GNU package maintainers want this? > > I always thought that GNU package maintainers want their entire > package to > be compiled with the same CFLAGS and CPPFLAGS. Would compiling the > gnulib > part with options for fewer warnings be OK with you? > > Paul, Pádraig, Jim, Paul, Akim, Simon, all: what's your opinion? In general I think different code need different flags. Some things I consider a no-no in my own code is not something I would enforce on gnulib code, and vice versa. 1) It is already possible to do this, just write a local Makefile.am and use gnulib-tool --makefile-name=gnulib.mk and do local compile flag changes. I do this sometime to disable -Werror for gnulib but I want the -Werror flag to be enabled for my own code. 2) Sometimes building gnulib with the package flags results in improvements to gnulib that I wouldn't otherwise notice. I recall lots of fixes to gnulib originating this way. 3) Sometimes building gnulib with the package flag causes problems, in the past this happened with -Werror and I've stopped using -Werror by default (I think) because gnulib's code tends to be more fragile when it comes to compiler-specific detailed warnings than some of my own code. 4) I'd like separate --enable-silent-rule settings for gnulib and my own code. When developing from git, I really don't want to see all of gnulib's output but I would like to see the project's own output. This is probably possible to achieve using a gnulib.mk approach. Having native support for --enable-silent-gnulib-rules or support for 'make V=2' would be useful. /Simon signature.asc Description: This is a digitally signed message part
Re: different CFLAGS for gnulib code?
On 1/15/21 12:55 AM, Bruno Haible wrote: Would compiling the gnulib part with options for fewer warnings be OK with you? Not only is it OK, it's routine. Coreutils, Emacs, etc. do it.
Re: different CFLAGS for gnulib code?
Bruno Haible writes: > I always thought that GNU package maintainers want their entire package to > be compiled with the same CFLAGS and CPPFLAGS. Would compiling the gnulib > part with options for fewer warnings be OK with you? Just note that none of the warnings and errors I complained about recently occur when compiling gnulib, which I compile without any extra warning flags anyway. They occur when compiling my own C++ code that include gnulib's headers. -- Alexandre Duret-Lutz
different CFLAGS for gnulib code?
Hi, Jeffrey Walton wrote: > Perhaps it would be a good idea to filter-out the options that you > don't want present for Gnulib. > > If you are doing it during configure, then take the user's CFLAGS (or > CXXFLAGS) and then: > >TCFLAGS=`echo $CFLAGS | sed -e 's/-Wall//g' -e 's/-Wextra//g' > -e 's/-Werror//g'` > > If you are doing it during make, then use a recipe like this for Gnulib > sources: > > GL_CFLAGS := $(filter-out -Wall -Wextra -Werror% -Wunused > -Wconversion -Wp%, $(CFLAGS)) > ... > %.o:%.c: > $CC $(strip $CPPFLAGS $GL_CFLAGS -c) $< > > That will put an end to these mailing list messages and bug reports. > You get what you want, and users get what they want. > > Otherwise, this is an exercise in insanity. Users keep doing the same > thing, GNU keeps doing the same thing, but everyone expects a > different outcome. Instead of practicing inanity, engineer a fix for > the problem. It is an interesting idea. Leaving the question aside how it is implemented (through an AC_SUBSTed variable or what else), the main question is: Would some GNU package maintainers want this? I always thought that GNU package maintainers want their entire package to be compiled with the same CFLAGS and CPPFLAGS. Would compiling the gnulib part with options for fewer warnings be OK with you? Paul, Pádraig, Jim, Paul, Akim, Simon, all: what's your opinion? Bruno