GNU bug report logs - #7689
Disable portability warnings about make portability issues only?

unarchive 7689

From: Philip Prindeville <philipp_subx <at> redfish-solutions.com>
To: bug-automake <at> gnu.org
Subject: Fwd: Due for a new release?
Date: Mon, 20 Dec 2010 11:15:55 -0800

The odd thing is that even though it complains, it still generates the correct Makefile in the first case:

SYMFILES = $(srcdir)/uni.h $(shell $(CC) $(CFLAGS) -E $(srcdir)/header.c | $(AWK) -f $(srcdir)/script.awk)

Does automake need to be $(shell ...)-aware?

-------- Original Message --------
Subject: 	Due for a new release?
Date: 	Sun, 19 Dec 2010 20:14:28 -0800
From: 	Philip Prindeville <philipp_subx <at> redfish-solutions.com>
To: 	linux-atm-general <at> lists.sourceforge.net

2.5.1 has now been out over a year.

Noticed that there are some issues w/ building this version, especially in cross-compilation environments.

...
Running libtoolize...
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: You should add the contents of the following files to `aclocal.m4':
libtoolize:   `/usr/share/aclocal/libtool.m4'
libtoolize:   `/usr/share/aclocal/ltoptions.m4'
libtoolize:   `/usr/share/aclocal/ltversion.m4'
libtoolize:   `/usr/share/aclocal/ltsugar.m4'
libtoolize:   `/usr/share/aclocal/lt~obsolete.m4'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
Running aclocal...
Running autoconf...
Running autoheader...
Running automake...
src/q2931/Makefile.am:21: shell $(CC: non-POSIX variable name
src/q2931/Makefile.am:21: (probably a GNU make extension)
src/qgen/Makefile.am:8: `CFLAGS' is a user variable, you should not override it;
src/qgen/Makefile.am:8: use `AM_CFLAGS' instead.
Finished...  Now run './configure' and 'make'...
...

The first warning comes from:

SYMFILES = $(srcdir)/uni.h $(shell $(CC) $(CFLAGS) -E $(srcdir)/header.c | $(AWK) -f $(srcdir)/script.awk)

and the second warning from:

CFLAGS = @CFLAGS_FOR_BUILD@

Could we do a little cleanup on it and release 2.5.2?

Thanks,

-Philip

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 7689 <at> debbugs.gnu.org
Cc: Philip Prindeville <philipp_subx <at> redfish-solutions.com>,
	Nick Bowler <nbowler <at> elliptictech.com>
Subject: Re: bug#7689: Fwd: Due for a new release?
Date: Thu, 23 Dec 2010 00:24:34 +0100

tags 7689 notabug
close 7689
thanks

On Monday 20 December 2010, Philip Prindeville wrote:
> The odd thing is that even though it complains, it still generates the correct Makefile in the first case:
> 
> SYMFILES = $(srcdir)/uni.h $(shell $(CC) $(CFLAGS) -E $(srcdir)/header.c | $(AWK) -f $(srcdir)/script.awk)
> 
> Does automake need to be $(shell ...)-aware?
> 
This is not a bug, as Nick has clearly explained here (BTW, thanks
Nick for this!):
 <http://lists.gnu.org/archive/html/automake/2010-12/msg00051.html>

So I'm closing it.

Philip, if you've been confused on this issue by the automake manual,
and have specific complaints or suggestions for improvement, feel free
to open a new bug report.  Thanks.

Regards,
  Stefano

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Philip Prindeville <philipp_subx <at> redfish-solutions.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 7689 <at> debbugs.gnu.org
Subject: Re: bug#7689: Fwd: Due for a new release?
Date: Thu, 23 Dec 2010 01:36:41 +0100

reopen 7689 !
tags 7689 -notabug
severity 7689 whishlist
retitle 7689 Disable portability warnings about make portability issues only?
thanks

On Thursday 23 December 2010, Philip Prindeville wrote:
> On 12/22/10 3:24 PM, Stefano Lattarini wrote:
> > tags 7689 notabug
> > close 7689
> > thanks
> >
> > On Monday 20 December 2010, Philip Prindeville wrote:
> >> The odd thing is that even though it complains, it still generates the correct Makefile in the first case:
> >>
> >> SYMFILES = $(srcdir)/uni.h $(shell $(CC) $(CFLAGS) -E $(srcdir)/header.c | $(AWK) -f $(srcdir)/script.awk)
> >>
> >> Does automake need to be $(shell ...)-aware?
> >>
> > This is not a bug, as Nick has clearly explained here (BTW, thanks
> > Nick for this!):
> >   <http://lists.gnu.org/archive/html/automake/2010-12/msg00051.html>
> >
> > So I'm closing it.
> >
> > Philip, if you've been confused on this issue by the automake manual,
> > and have specific complaints or suggestions for improvement, feel free
> > to open a new bug report.  Thanks.
> >
> > Regards,
> >    Stefano
> 
> No, not confused.  Just seems counter-intuitive that a GNU utility would have
> the default behavior of complaining when you use other GNU utilities... or
> syntax particular to them.
> 
> It might make more sense to have automake assume that it is being used with
> gmake, and then have a specific option to explicitly turn off that behavior.
> 
Well, since one of the primary goals of Automake is generating *portable*
Makefiles (and believe me it goes through considerable pain to do so), its
behaviour is perfectly rational in this regard.

That said, I think that having more granular warnings about make-only
portability issues might make sense; so that a developer interested in
supporting only GNU make could do something like:

  AUTOMAKE_OPTIONS([-Wall -Wno-make-portability])

and then safely use GNU extensions in his Makefile.am, while preserving
all the other portability warnings provided by Automake.

In light of this, I'm re-opening and re-titling this bug (with severity
"whishlist" this time).

Thanks,
   Stefano

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Philip Prindeville <philipp_subx <at> redfish-solutions.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 7689 <at> debbugs.gnu.org
Subject: Re: bug#7689: Fwd: Due for a new release?
Date: Thu, 23 Dec 2010 12:05:09 +0100

On Thursday 23 December 2010, Philip Prindeville wrote:
> On 12/22/10 4:36 PM, Stefano Lattarini wrote:
> > Well, since one of the primary goals of Automake is generating *portable*
> > Makefiles (and believe me it goes through considerable pain to do so), its
> > behaviour is perfectly rational in this regard.
> >
> > That said, I think that having more granular warnings about make-only
> > portability issues might make sense; so that a developer interested in
> > supporting only GNU make could do something like:
> >
> >    AUTOMAKE_OPTIONS([-Wall -Wno-make-portability])
> >
> > and then safely use GNU extensions in his Makefile.am, while preserving
> > all the other portability warnings provided by Automake.
> >
> > In light of this, I'm re-opening and re-titling this bug (with severity
> > "whishlist" this time).
> >
> > Thanks,
> >     Stefano
> 
> Changing the default to do this would probably better satisfy the Principle
> of Least Astonishment. :-)
> 
I disagree.  When passing `-Wall', you are asking automake to report to
you *all* the warnings about *all* the problems it's able to find.  And
automake does so.  This is Least Astonishment for me.  And since automake
is all about portability, it's natural (even required I'd say) that it is
able to find out and report possible portability problems.

If, after having enabled -Wall, you decide you're not really interested
in a particular class of warnings, you can tell automake not to report
the warnings in that class:

  AUTOMAKE_OPTIONS = -Wall -Wno-portability

This is a consistent and good policy IMO; the only blemish is that it's
currently somewhat lacking in granularity for the warning categories...
which is what this bug report is about now ;-)

Regards,
   Stefano

From: Philip Prindeville <philipp_subx <at> redfish-solutions.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 7689 <at> debbugs.gnu.org
Subject: Re: bug#7689: Fwd: Due for a new release?
Date: Wed, 22 Dec 2010 16:15:32 -0800

On 12/22/10 3:24 PM, Stefano Lattarini wrote:
> tags 7689 notabug
> close 7689
> thanks
>
> On Monday 20 December 2010, Philip Prindeville wrote:
>> The odd thing is that even though it complains, it still generates the correct Makefile in the first case:
>>
>> SYMFILES = $(srcdir)/uni.h $(shell $(CC) $(CFLAGS) -E $(srcdir)/header.c | $(AWK) -f $(srcdir)/script.awk)
>>
>> Does automake need to be $(shell ...)-aware?
>>
> This is not a bug, as Nick has clearly explained here (BTW, thanks
> Nick for this!):
>   <http://lists.gnu.org/archive/html/automake/2010-12/msg00051.html>
>
> So I'm closing it.
>
> Philip, if you've been confused on this issue by the automake manual,
> and have specific complaints or suggestions for improvement, feel free
> to open a new bug report.  Thanks.
>
> Regards,
>    Stefano

No, not confused.  Just seems counter-intuitive that a GNU utility would have the default behavior of complaining when you use other GNU utilities... or syntax particular to them.

It might make more sense to have automake assume that it is being used with gmake, and then have a specific option to explicitly turn off that behavior.

From: Philip Prindeville <philipp_subx <at> redfish-solutions.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 7689 <at> debbugs.gnu.org
Subject: Re: bug#7689: Fwd: Due for a new release?
Date: Wed, 22 Dec 2010 17:21:07 -0800

On 12/22/10 4:36 PM, Stefano Lattarini wrote:
> reopen 7689 !
> tags 7689 -notabug
> severity 7689 whishlist
> retitle 7689 Disable portability warnings about make portability issues only?
> thanks
>
> On Thursday 23 December 2010, Philip Prindeville wrote:
>> On 12/22/10 3:24 PM, Stefano Lattarini wrote:
>>> tags 7689 notabug
>>> close 7689
>>> thanks
>>>
>>> On Monday 20 December 2010, Philip Prindeville wrote:
>>>> The odd thing is that even though it complains, it still generates the correct Makefile in the first case:
>>>>
>>>> SYMFILES = $(srcdir)/uni.h $(shell $(CC) $(CFLAGS) -E $(srcdir)/header.c | $(AWK) -f $(srcdir)/script.awk)
>>>>
>>>> Does automake need to be $(shell ...)-aware?
>>>>
>>> This is not a bug, as Nick has clearly explained here (BTW, thanks
>>> Nick for this!):
>>>    <http://lists.gnu.org/archive/html/automake/2010-12/msg00051.html>
>>>
>>> So I'm closing it.
>>>
>>> Philip, if you've been confused on this issue by the automake manual,
>>> and have specific complaints or suggestions for improvement, feel free
>>> to open a new bug report.  Thanks.
>>>
>>> Regards,
>>>     Stefano
>> No, not confused.  Just seems counter-intuitive that a GNU utility would have
>> the default behavior of complaining when you use other GNU utilities... or
>> syntax particular to them.
>>
>> It might make more sense to have automake assume that it is being used with
>> gmake, and then have a specific option to explicitly turn off that behavior.
>>
> Well, since one of the primary goals of Automake is generating *portable*
> Makefiles (and believe me it goes through considerable pain to do so), its
> behaviour is perfectly rational in this regard.
>
> That said, I think that having more granular warnings about make-only
> portability issues might make sense; so that a developer interested in
> supporting only GNU make could do something like:
>
>    AUTOMAKE_OPTIONS([-Wall -Wno-make-portability])
>
> and then safely use GNU extensions in his Makefile.am, while preserving
> all the other portability warnings provided by Automake.
>
> In light of this, I'm re-opening and re-titling this bug (with severity
> "whishlist" this time).
>
> Thanks,
>     Stefano

Changing the default to do this would probably better satisfy the Principle of Least Astonishment. :-)

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 7689 <at> debbugs.gnu.org
Subject: wontfix
Date: Mon, 25 Jun 2012 11:41:20 +0200

tags 7689 wontfix
close 7689
thanks

I'm closing this bug report.  Packages that are not interested in being
portable to non-GNU makes are now advised to use the Automake-NG fork
instead: <https://lists.gnu.org/mailman/listinfo/automake-ng>

Regards,
  Stefano

GNU bug report logs - #7689 Disable portability warnings about make portability issues only?

GNU bug report logs - #7689
Disable portability warnings about make portability issues only?