Re: different CFLAGS for gnulib code?

2021-01-17 Thread Pádraig Brady

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?

2021-01-15 Thread Darshit Shah



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?

2021-01-15 Thread Jim Meyering
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?

2021-01-15 Thread Simon Josefsson via Gnulib discussion list
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?

2021-01-15 Thread Paul Eggert

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?

2021-01-15 Thread Alexandre Duret-Lutz
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?

2021-01-15 Thread Bruno Haible
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