Re: 03-remove-clean-am-files.patch

[Tom Tromey]

Akim> I do agree introducing ?INSTALL? obfuscates, but I still have
Akim> if/fi in mind.  The reason I didn't implement if/fi support is
Akim> that I want to use the same as for Makefile.am, but improving it
Akim> with support for TRUE and FALSE directly, in which case there is
Akim> no @FOO_TRUE@ etc. to output, just statically perform the if.

I don't want to unify the .am readers for 1.5.  My experience is that
automake users have all kinds of ugly stuff in their Makefile.am.  We
definitely don't want to support this stuff long-term, but I think
changing it now would be ill-advised.

Akim> So the plan is that we keep ?FOO? but instead of destroying
Akim> ?FOO? will evaluate to TRUE/FALSE and then the regular if/fi
Akim> mechanism will be usable.

Are you saying you'd change this:

    if ?FOO?
    ...
    endif

to `if TRUE' or `if FALSE' depending on how `?FOO?' is set by
&transform?

That's ok, I guess, though I'd prefer not to take the names `TRUE' and
`FALSE' away from the user.  It seems a bit baroque for the short
(1.5) term given that reader unification isn't going to happen.

Akim> But before handling the conditionals, I still have things to
Akim> understand about them.  Also, unconditional values should be
Akim> seen as conditional values, for instance corresponding to TRUE.

I don't understand this.  Why would you want an unconditional
conditional?

Akim>   * automake.in (&handle_programs, &handle_libraries, &handle_tags)
Akim>   (&handle_ltlibraries, &handle_emacs_lisp, &handle_python): Adjust.
Akim>   (&am_install_var): Forget about `-clean'.
Akim>   Transform ?INSTALL?.
Akim>   Always output the *.am file.
Akim>   * data-clean.am, java-clean.am, libs-clean.am, lisp-clean.am,
Akim>   * ltlib-clean.am, progs-clean.am, python-clean.am, tags-clean.am:
Akim>   Remove, merged into the corresponding *.am file.
Akim>   * data.am, libs.am, ltlib.am, progs.am, python.am: Equip with
Akim>   ?INSTALL?.

This is ok.

Tom