Re: AM_SUBST_IGNORE = AC_SUBST without Makefile variable definition

[Stepan Kasal]

Hello Alexandre,

> I still haven't completely understood the reaction to the earlier version of
> this patch.

I apologize for that.

It took me some time to form my opinion, and the explanation of my position will
be a bit lengthy.  (These are some of the reasons why I failed to answer 
earlier.)

I'd like to vote for rejecting this patch.

The patch solves the following problems:

1) fixes problems with values ending with a backslash,
2) enables usage of multiline variables
3) reduces Makefile.in bloat

I believe all these problems will be ultimately fixed by a different code.
(See below for details.)
It became clear now that that code won't be ready for 2.60, though.

This means that from my perspective, your patch is not needed as a long-term
solution, but offers an immediate solution for current needs.
The disadvantage is that it pollutes the Autoconf API, and I don't think
it's worth it.

I understand that some immediate fixes for the above problems might be good,
namely:

ad 1) I think the current hack for AMDEPBACKSLASH can stay for now.

ad 2) Do not advertise the multiline substitutions so much; the Autoconf
NEWS file shall say that the implementation is not finished, as they are not
compatible with Automake.

ad 3) Well, it's an optimization only.  If you think it's an urgent issue,
you can use an undocumented _AM_SUBST_NOTMAKE trace to spped things up
for Autoconf 2.60/Automake 1.10.
   
The description of the ``ultimate solution'':

Autoconf shall have AC_DUMP_SUBSTS which will dump all substituted variables
to $top_builddir/Make_substs, in a format suitable for make; with multiline
values and trailing backslashes properly sanitized.
Automake won't generate the huge list of variable assignments; instead there
will be one special line
        @ac_include_substs@
which will be translated by ./configure to something like
`include ../Make_substs'
(If the make doesn't support any form of include directive, the file will
be copied in, but that rare these days.)

With this code in place, AM_SUBST_NOTMAKE will not have any significant
advantage anymore.  Moreover, it'll be necessary to reimplement the feature
in Autoconf.  Consequently, I'd prefer if this feature is not added to the
public interface.

I apologize again that I wasn't able to communicate this earlier.

Stepan Kasal