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