Re: Appending to builtin Automake variables from an included file

[Allan Caffee]

On Sat, 28 Feb 2009, Ralf Wildenhues wrote:
> * Allan Caffee wrote on Thu, Feb 26, 2009 at 02:49:16PM CET:
> > That is certainly one possibility.  Unfortunately though that means that
> > in the Makefile.am files you _must_ use += since Automake will error out
> > if you assign more than one value to a variable (within the same
> > Automake conditional block).
>
> Which is a good thing: two assignments are a potential error, and will
> often result in something undesirable.

Very true.

> > Modern Automake does support appending.  But only appending to a
> > variable that has already been set.
>
> Yes.  This is done primarily to be able to diagnose typos, e.g.,
>   foolish =
>   foo1ish += bar
>
> (no pun intended, BTW), but also to provide more deterministic semantics
> in the presence of conditionals (I don't remember the details).
>
> Is it worth the hassle?  It's certainly a trade-off:
> - more work due to required initializations of all variables,
> - OTOH typos in variables can have rather subtle implications,
>   esp. if those variables are of the "magic automake" kind.

I had never thought of it that way, that does seem like a pretty useful
check.

> I suppose a more sophisticated implementation would allow to let
> automake work in a mode that wouldn't error out on += for uninitialized
> variables (e.g., with a command line switch -Wno-var-append or so).
>
> [...]
>
> I think thinking through the special cases that can come up with
> conditionals would be most of the work.  If you want to contribute a
> patch, please read the HACKING file in the git tree.

Actually the more I think about what I wanted to do the messier it
seems.  In order to abstract whatever changes were made in the snippet
completely from the Makefile.am using this approach we would have to
allow `=' to be semantically identical to `+='.  For obvious reasons,
including those you mentioned, this would be _very_ ill advised.

I was thinking instead it might be worthwhile to provide a hook target
like the one I mentioned in a previous post.  For example imagine the
following scenario:

        am/doxygen.am:
distclean-am-hook:
        -rm -rf Doxyfile doc/html
# ...

        am/dist_rpm.am:
distclean-am-hook:
        -rm -f template.spec
# ...

        Makefile.am:
include $(top_srcdir)/am/doxygen.am
include $(top_srcdir)/am/dist_rpm.am

In such a case Automake could rename these targets to
am--distclean-am-hook-1 and am--distclean-am-hook-2 respectively and add
them to as dependencies of distclean-am.  This would allow third party
snippets to clean up after themselves without any effort on the
maintainer of Makefile.am and without messing around with user-space
variables.  Would this be an acceptable extension to Automake?

~Allan