tech-toolchain archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: make: dealing with targets with multiple outputs
On Thu, May 30, 2019 at 01:27:51PM -0700, Simon J Gerraty wrote:
> A common gripe about make is how it handles (or doesn't depending on
> pov) targets that generate multiple outputs.
> The classic case being yacc but there are far worse examples.
>
> I was discussing this with bdrewery at last BSDCan, and came up with the
> idea of a new special src to mark a set of targets as being a unit.
> Eg.
>
> foo.c foo.h: foo.y .NAMING_STUFF_IS_HARD
>
> The intent being that if any of the targets are out-of-date or missing
> the script for just one (the first one would be an obvious choice)
> should be run, and when it is marked up to date so are it's companions.
>
> This would require yet another Lst in GNode.
>
> Thoughts?
> [my subscription might be busted so cc welcome]
We already have a solution for this problem, it's just waiting for
someone to find time to implement it.
Namely: given multiple targets on the left, don't schedule them in
parallel, and after building the first one check to see how many of
the others also got knocked off at the same time.
This covers the common case (multiple outputs) and works transparently
for the other case (recipe shared over multiple independent targets)
at some loss of parallelism.
If you are using the uncommon case on purpose and you want the
parallelism back, you can write it with a for loop:
foo.c bar.c baz.c: stuff
recipe
becomes
.for T in foo.c bar.c baz.c
$(T): stuff
recipe
.endfor
which in most cases is preferred anyway.
I don't remember when I originally proposed this but I think it's been
several years :(
--
David A. Holland
dholland%netbsd.org@localhost
Home |
Main Index |
Thread Index |
Old Index