[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New feature: Post-requisites

From: Alejandro Colomar
Subject: Re: New feature: Post-requisites
Date: Mon, 25 Jul 2022 13:54:09 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.0.2

Hi Edward,

On 7/25/22 11:06, Edward Welbourne wrote:
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.

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

The same way that having dep loops right now is an error, I'd just throw an error if a post-requisite creates a dependency loop.



Alejandro Colomar

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]