Re: [bug #13976] Regression in :: deps handling between V3.76 and V3.80

[Paul D. Smith]

%% Boris Kolpackov <address@hidden> writes:

  >> The rules I mentioned in this list apply only between the two
  >> prerequisites listed, in that pathway.  If the "waited for" prerequisite
  >> appears on any other path where it is not waited for, then it's fair
  >> game for parallelization.

  bk> I find it somewhat counter-intuitive. The appearance of the .WAIT
  bk> "separator" places a restriction on what make can do. Having
  bk> somewhere else a rule that relaxes this restriction is a bad idea.

I disagree, actually.  It's a settled feature of make that the DAG is
not a simple tree: that there can be more than one pathway to a given
target in the DAG.

The placement of the .WAIT prerequisite implies a relationship between
two prerequisites of a given target; I don't think it's odd to assume
that it does not imply anything about any other relationship between those
same files, as targets or prerequisites.

Look at it this way: envision the DAG.  I would say that .WAIT is a
block on one of the edges between two nodes in the DAG.  If that same
node can be accessed through other edges, then that's fine: the .WAIT
block doesn't apply to those.

Make sense?  Or still no?


I WON'T implement this particular .WAIT feature if it has a more full
semantic, in that it applies to a given node instead of to an edge
between nodes.  If we decide to choose that type of semantic then this
construct (.WAIT between prerequisites) is really inappropriate (as I'm
sure you agree).

An even more complete notation might involve using parens or something
to create "blocks" of prerequisites, but in reality I don't think
something of that complexity is necessary.

  >> Can you be a little more detailed about what you were thinking, Boris?

  bk> Ok, the ordinary TARGET:PREREQUISITE relationship can be defined as:

  bk>  (1) If TARGET is brought up-to-date then PREREQUISITE is brought
  bk>      up-to-date

  bk>  (2) If PREREQUISITE is newer then TARGET then TARGET is remade

  bk>  (3) If both TARGET and PREREQUISITE are remade then PREREQUISITE is
  bk>      made before TARGET.

OK.

  bk> Then, the so-called order-only relationship, TARGET:|PREREQUISITE,
  bk> would be obtained by removing (2) from the above:

  bk>  (1) If TARGET is brought up-to-date then PREREQUISITE is brought
  bk>      up-to-date

  bk>  (2) If both TARGET and PREREQUISITE are remade then PREREQUISITE is
  bk>      made before TARGET.

  bk> Now, if we further relax the requirements and remove (1), we will
  bk> get what I call "truly order-only" prerequisites:

  bk>  (2) If both TARGET and PREREQUISITE are remade then PREREQUISITE is
  bk>      made before TARGET.

OK.  I'm not sure where this would be useful but OK :-).

  bk> It is obvious that you don't need such "truly order-only"
  bk> prerequisites unless you are doing something behind make's
  bk> back. That's why I believe we don't need either .WAIT or "truly
  bk> order-only" prerequisites. If I had to chose between the two I
  bk> would go with the "truly order-only" prerequisites for it is a
  bk> clean, coherent and easy to explain extension.

  bk> For example, if the syntax for such a feature were
  bk> TARGET:&PREREQUISITE then instead of

  bk> all: foo fox
  bk> foo: bar .WAIT baz
  bk> fox: bar baz

  bk> we would write

  bk> all: foo fox
  bk> foo fox: bar baz
  bk> bar: &baz

But, this doesn't do the same thing as .WAIT.  Or, if it does, then you
haven't captured it in your discussion.

The big advantage that .WAIT has over order-only prereqs is that it
applies a block to an edge in the graph: it says that make will go no
farther down that particular edge of the graph until all the "older
siblings" of this node (the nodes that appear before it in the prereq
list) are completed.

Neither order-only prereqs, nor "truly order-only" prereqs, have that
feature.  That is, if you want them to apply to all the prerequisites of
the targets as well you have to list them all in the makefile.

Example:

    all: foo .WAIT bar
    foo: fee fie foe fum
    bar: biz baz boz booz

In this setup, regardless of the -j setting, foo, fee, fie, foe, and fum
would ALL be completely processed before ANY of bar, biz, baz, boz, or
booz.

To emulate this with order-only prereqs you'd have to write it all out:

    all: foo bar
    foo: fee fie foe fum
    bar: biz baz boz booz

    foo fee fie foe fum: | bar biz baz boz booz

Here, of course, this isn't so onerous but it's easy to see this gets
just as annoying as, for example, the use of order-only prereqs to
create directories, where you have to list it for every possible
target.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist