%% Boris Kolpackov <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
