emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Emacs-bug-tracker] bug#7669: closed (option "foreign" after "-Wall" tur


From: GNU bug Tracking System
Subject: [Emacs-bug-tracker] bug#7669: closed (option "foreign" after "-Wall" turns off and portability warnings.)
Date: Sat, 15 Jan 2011 20:23:02 +0000

Your message dated Sat, 15 Jan 2011 21:28:39 +0100
with message-id <address@hidden>
and subject line Re: bug#7669: option "foreign" after "-Wall" turns off and 
portability warnings.
has caused the GNU bug report #7669,
regarding option "foreign" after "-Wall" turns off and portability warnings.
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
7669: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7669
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: option "foreign" after "-Wall" turns off and portability warnings. Date: Fri, 17 Dec 2010 19:52:29 +0100 User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )
Hello automakers.

This is basically just a reproposal of PR/547 from the old gnats database;
I'm resubmitting it here because I'd really like to see it fixed, and
having it reported in the new, more visible debbugs-based bug database
might help in this respect.

-*-*-*-

With automake >= 1.10, foreign *after* -Wall in AM_INIT_AUTOMAKE turns
off portability warnings.

  $ cat >> configure.ac <<'END'
  AC_INIT([foo], [1.0])
  AM_INIT_AUTOMAKE([foreign -Wall])
  AC_CONFIG_FILES([Makefile])
  AC_PROG_CC
  END
  $ aclocal
  $ cat > Makefile.am <<'END'
  CFLAGS := $(wildcard *)
  bin_PROGRAMS = foo
  END
  $ automake -a # will warn as expected
  Makefile.am:1: `:='-style assignments are not portable
  Makefile.am:1: wildcard *: non-POSIX variable name
  Makefile.am:1: (probably a GNU make extension)
  Makefile.am:1: `CFLAGS' is a user variable, you should not override it;
  Makefile.am:1: use `AM_CFLAGS' instead.
  $ # now put `foreign' after `-Wall'
  $ sed -i 's/foreign -Wall/-Wall foreign/' configure.ac
  $ automake -a # gives no warnings!
  $ automake -a -Wall # but this does, luckily
  Makefile.am:1: `:='-style assignments are not portable
  Makefile.am:1: wildcard *: non-POSIX variable name
  Makefile.am:1: (probably a GNU make extension)
  Makefile.am:1: `CFLAGS' is a user variable, you should not override it;
  Makefile.am:1: use `AM_CFLAGS' instead.

While the current behaviour is due to various historical and implementation
reasons, IMHO it is counter-intuitive and somewhat "dangerous", since
programmers enabling the `foreign' option might unwittingly be prevented
from seeing portability warnings -- when they think to have enabled those
warnings!

Regards,
   Stefano



--- End Message ---
--- Begin Message --- Subject: Re: bug#7669: option "foreign" after "-Wall" turns off and portability warnings. Date: Sat, 15 Jan 2011 21:28:39 +0100 User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )
On Thursday 23 December 2010, Stefano Lattarini wrote:
> On Sunday 19 December 2010, Ralf Wildenhues wrote:
> > * Stefano Lattarini wrote on Fri, Dec 17, 2010 at 07:52:29PM CET:
> > > With automake >= 1.10, foreign *after* -Wall in AM_INIT_AUTOMAKE turns
> > > off portability warnings.
> > 
> > > While the current behaviour is due to various historical and 
> > > implementation
> > > reasons, IMHO it is counter-intuitive and somewhat "dangerous", since
> > > programmers enabling the `foreign' option might unwittingly be prevented
> > > from seeing portability warnings -- when they think to have enabled those
> > > warnings!
> > 
> Now I've posted a patch series about this; see:
>  <http://lists.gnu.org/archive/html/automake-patches/2010-12/msg00139.html>
> 
The patch series has been applied (with some churns and amendings), see:
 <http://lists.gnu.org/archive/html/automake-patches/2011-01/msg00039.html>
 <http://lists.gnu.org/archive/html/automake-patches/2011-01/msg00170.html>
and merged to master with commit `v1.11-640-gf4f5bbe'.

This should fix the bug.

Regards,
  Stefano


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]