On 7/22/22 16:20, Paul Smith wrote:
>> So, after all the "normal" goal targets were completed make would
>> proceed to run any "extra" goal targets that were added as part of
>> the processing of the "normal" goal targets. Then after the those
>> "extra" goal targets were complete, make would proceed to run any
>> "new extra" goal targets that were added as part of THAT processing.
>> Etc.
How would any new targets be added ? Surely make's dependency graph
would ensure that you know what you'll be building before you start,
regardless of whether it's a prerequisite or a postrequisite.
>> Since of course we never build the same target twice in a single
>> instance of make, this cannot result in an infinite loop.
But for the dependency graph, this would be a problem: if it were
possible to discover a need for a postrequisite during processing of
postrequisites, and that postrequisite had already been built (because
somehow make was unaware that it would be needed later), then we'd
either built it twice (or more) or fail to build it after a target
(triggered by a postrequisite, possibly itself) queued it to be built
because we need its command to be run after the one that asked for it.
>> However this would need a more detailed specification.
Indeed - for example, if a target is specified *both* as a prerequisite
of some target that does get built *and* as a postrequisite of some rule
we do exercise, it has to be built both before and after, which violates
the "only build once" rule above. However, as long as the dependency
tree does in fact enable you to know before you start what you're going
to build, such repeat building should not be a problem. It is built
before the first target that has it as a prerequisite and after the last
that has it as a postrequisite.
Also, this new feature smells like it may open up some interesting
corner-cases in dependency-loop analysis, although I can't think of any
immediately.
>> For example does a "post-requisite" get built only if its target is
>> considered out of date and its recipe invoked? Or does it get built
>> if the target is considered, regardless of whether it's up-to-date?
The logic that motivates the feature, at least, argues for the
postrequisite to only be queued for refresh if make runs the command to
rebuild the target that has it as post-requisite. If we don't install
the new library, makefile, &c., we don't need to run the "update my
system's knowledge of that" command.
The alternative, in any case, amounts to saying that whenever make even
checks that a target is up to date (and even if it is) we must run all
the post-conditions of anything it depends on. That sounds like a lot
of wanton re-building on a no-op; and better handled by having a script
that runs those commands, that you can run independently of make, or
that might wrap make to check things are up to date and then
unconditionally run a bunch of post-make commands.
>> Also, is it up to make to FORCE the post-requisite to be built, if
>> its target was built? Or is it only rebuilt if it's considered out
>> of date in its own right as a normal target?
Alejandro Colomar (Friday, July 22, 2022 16:38) replied:
> I'd say that post-requisites need only be build if they are not
> up-to-date. Let the user tell make(1) that a post-requisite needs to
> be build regardless of its up-to-date status by marking it .PHONY or
> FORCE.
+1 to that.
Eddy.
