Re: AM_SUBST_IGNORE = AC_SUBST without Makefile variable definition

[Ralf Wildenhues]

Hi Simon, Stepan,

* Simon Richter wrote on Wed, Oct 19, 2005 at 08:53:55AM CEST:
> Stepan Kasal schrieb:
> 
> > AC_SUBST([FOO], ["foo
> > bar"])

> > Automake could generate lines like this:
> 
> > FOO = @FOO@@\n@
> 
> There are a lot of cases, in fact, the majority, where the substituted
> string is only known at configure time, when the Makefile.in files have
> long been generated.

I believe what Stepan meant was:
If the status.m4 code encounters  address@hidden@@\n@', where `FOO' has been
AC_SUBSTed, then treat the replacement of the complete string
address@hidden@@\n@' in a special way.

I would oppose this suggestion if it were used as default setting
created by Automake, unless an actual implementation can be shown not to
show execution time regression inside config.status.

> What might be doable would be substituting the newlines at configure
> time with $N, and let automake make sure that $N is defined as a single
> newline.

What would actually be most useful:
Just do not use anything in a Makefile that may end up containing a
newline.

Rationale: you just can't portably get a `make' macro to contain a
newline.  So you might as well not try to.

If you accept that fact, you might as well flatten the variable before
substituting it.

This makes introducing a different macro useful, that will cause
substitutions but not in Makefile.in's.  Note that this is not
necessarily quite the same as not having Automake write a line

  FOO = @FOO@

in Makefile.in; it also means that any occurrence of
  @FOO@ 
in a Makefile.in will be substituted by $FOO_FLATTENED rather than $FOO,
if I may say so informally.  I do not know if there is any way we can
detect this automatically, though (whether a CONFIG_FILE will end up in
a Makefile).

Surely the latter requirement may also be fulfilled by changing
documentation only, i.e.: `for any @FOO@ in a Makefile.am, make sure
$FOO will not contain a newline; same applies to hashes `#', by the way,
at least for portable `make'.  Since packages may be restricted to
more powerful `make' implementations anyway, some of these restrictions
may not apply;  IOW, let the user have the choice.

Cheers,
Ralf