bug-gnulib
[Top][All Lists]
Advanced

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

Re: FreeBSD GCC warnings


From: Ralf Wildenhues
Subject: Re: FreeBSD GCC warnings
Date: Sat, 18 Oct 2008 14:31:31 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hi Bruno,

* Bruno Haible wrote on Sat, Oct 18, 2008 at 12:59:30PM CEST:
> >Maybe it is time to publish AM_SUBST_NOTMAKE which is like AC_SUBST
> 
> Of course! Currently, in projects which use automake, AC_SUBST with multiline
> values will only work if all lines except possibly the first one start with
> a '#'.

OK; I need to reread the long discussion about it back then (Stepan
argued quite against publishing it), to see whether there are blockers
that need to be addressed first.  (FWIW, searching for AM_SUBST_NOTMAKE
will find the discussion right away.)

> Additionally, I wanted to use the value in a Makefile command. But this
> resulted in an error message from 'make', because the Makefile looked like
> this:
> 
> stdlib.h: stdlib.in.h
>       sed -e 's/@PRAGMA_SYSTEM_HEADER@/#if __GNUC__ >= 3
> #pragma GCC system_header
> #endif/g' < stdlib.in.h > stdlib.h
> 
> So, what would be useful here, is a way to escape AC_SUBST values so that
> newlines and '#' characters are hidden from 'make' when the macro is used
> in the command section of a 'make' rule.

Please note that that would not save you in this particular case, for
several reasons:
- newlines that are to appear in the replacement part of a sed 's'
  command need escaped by a preceding backslash.  While most 'make'
  implementations will transport backslash-newline from a rule to
  the generated command, not all do so (IIRC some older GNU make
  didn't), and of course backslash-newline in macro definitions is
  flattened.
- some make implementations are notorious in that they consider
  everything following a '#' as comment, no matter where that thing
  appears (at least IIRC; I didn't retest any of this now).

So you'd need two different substs at least, one for your header, and
one for the makefile.

> IMO, this belongs in automake because
>   - AC_SUBST values are frequently used in Makefile commands,
>   - It's not not trivial to do this escaping in a way that would preserve
>     whitespace (or the lack of whitespace) at the end of the value,
>   - It's out of scope for autoconf to care about special kinds of files,
>     like Makefiles.

Yes; but that weren't the only objections that prevented
AM_SUBST_NOTMAKE from appearing back then.

Cheers,
Ralf




reply via email to

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