tech-toolchain archive

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

Re: make rule of multiple file generation (was Re: CVS commit: src/share/mk)



>> Surely the right fix is not to add kludges like "nodes.h: nodes.c",
>> but rather to have make grow a syntax that _does_ mean "here are
>> commands which generate all of these files from these sources"?
> Well, it does already mean that to some extent.

To a point.  It's what I thought it meant back when I first started
using make, and I daresay I wasn't alone.  Is make specified precisely
enough to settle just what that syntax _does_ mean?

> Using multiple targets on the left has ~always been used this way; it
> just breaks when parallelized.

Um.  Sounds as though you're saying this sis a bug in -j.  Or am I
misinterpreting?

Alternatively, an equally correct fix could be to give "a b: c d" the
`one set of commands builds multiple files' semantic and invent
something else for `I'm just abbreviating "a: c d" "b: c d" here'.  I
suspect that would break more existing Makefiles than the other way
around, though.

>> If we need a strawman syntax for it, I'll propose

>> target1 target2 ... :& dependency1 dependency2 ...
>>      ...commands as usual...

> What about

> target1 .AND target2: dep1 dep2 ...
>       $(STUFF)

I thought about that.  But it introduces complications; what would

a .AND b c d .AND e: f g h

mean, for example?

Hmm, how about parens?  Looking at that example, I could see it as
being equivalent to (a b) c (d e): f g h.

These have different implications when a pre-change make runs into a
post-change Makefile, which is bound to happen eventually.  (I'm not
entirely sure which set of implications I prefer, admittedly, and the
parentheses way is yet a third set of implications.)

> Note that this .AND is in a certain sense not actually different from
> .WAIT.

Well...they have similar results, but the semantics behind them are
quite different; the effects with .WAIT depend on make checking
timestamps immediately before building b and deciding to skip it.

I think I prefer .AND over .WAIT on grounds of "don't lie to make".
Using .WAIT declares a chronological dependency which does not actually
exist, doing so so that timestamp checking will optimize away the
undesired second run of the commands.  Using .AND (or :&, or whatever)
actually describes the correct state of affairs.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index