Re: 01-factor-all.patch

[Tom Tromey]

Akim> There is one big twofold change introduced by this change.
Akim> First all-redirect no longer exists.  In fact I don't even
Akim> understand why it existed

I don't remember.  It might have been to avoid putting config.h
machinery into &do_one_merge_target.  Or it might have been an obscure
relic from the past.

Akim> It is my understanding that to be sure that Makefiles are
Akim> properly rebuilt, we really need to have an action (not a
Akim> dependency) that runs all-am/recursive.  The good point is that
Akim> now, independently from the GNUism of Make, remaking Makefiles
Akim> is properly handled.  The bad point is that we are forking many
Akim> more makes than before.

I don't think it is actually important to support non-GNU make
implementations here.  We've never supported Makefile rebuilding with
vendor makes in the past.  No other GNU Makefile has.  We've also
never had a complaint about it.  Since it sounds like this change
adversely affects performance, I'm against it.

Also, `all' isn't the only time that Makefiles can be rebuilt.
They can be rebuilt by any target, at least with GNU make.
I think it doesn't make sense to support Makefile rebuilding with
`all' and not with other targets, since I think the goal here would be
to effectively emulate GNU make with losing make implementations.
But I really don't want to do that.

Ok, I see we currently have `all-am: Makefile'.
But that doesn't seem like it can be right.
And with GNU Make it is unnecessary.

Akim> I meant, `Makefile' must be done before `all', but not
Akim> `$(DATA)', which is now a dependency of all-am, not `all'.
Akim> There was no such distinction before, but for `config.h' (one
Akim> way to paraphrase the paragraph above is to say that now
Akim> `Makefile' and `config.h' have the same status wrt `all').  I
Akim> was very unsure of the status of $(BUILT_SOURCES) and made it
Akim> config.h-like, while $(DATA)-like was another valid choice.

You have to be careful touching BUILT_SOURCES.  In the past we forced
them to be built as a condition of building (`Makefile: $(BUILT_SOURCES)').
That is wrong.

Instead we want to make sure that BUILT_SOURCES are only built by
`all'.  (I'm sure that's what you're doing.)

The guide here is the comment in &handle_merge_targets:

            # We need to make sure config.h is built before we
            # recurse.  We also want to make sure that built sources
            # are built before any ordinary `all' targets are run.  We
            # can't do this by changing the order of dependencies to
            # the "all" because that breaks when using parallel makes.
            # Instead we handle things explicitly.

So yes, BUILT_SOURCES should be handled like config.h.  We must build
them before all-recursive (and before all-am in the no-recursion
case).

Akim> And now for something completely different: any reason not to
Akim> include -w on the #! line instead of the maintainer-check
Akim> target?

Probably not.

Akim>   Standardize the handing of `all' targets.

I don't want to approve this until we decide on the `all: Makefile'
change.  I'd prefer to simply drop it.

Akim> +    # FIXME: Where should this go to?
Akim> +    if (&variable_defined('lib_LTLIBRARIES') &&
Akim> + &variable_defined('bin_PROGRAMS'))
Akim> +    {
Akim> + $output_rules .= "install-binPROGRAMS: install-libLTLIBRARIES\n\n";
Akim> +    }

Really this code is just a hack.  It was introduced because we need to
install ltlibraries before programs that use them on systems that
require relinking during install.

This code only covers the most common case.  Ideally we'd have some
much smarter implementation.  For instance there can be install
ordering dependencies between libraries as well as between programs.

One idea would be to express these dependencies in Makefile.am (since
Makefile is all about expressing dependencies) and then somehow use
that information to guide the installs.  Probably not a quick project.

Tom