[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
a syntax for multitarget rules
From: |
Reinier Post |
Subject: |
a syntax for multitarget rules |
Date: |
Thu, 13 Nov 2014 14:43:45 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Mon Nov 10 21:44:33 2014, address@hidden (Nicholas Clark) wrote:
> Hi all,
>
> Lately I've been needing to work hard to get around GNU Make's lack of
> simultaneous multi-target recipes. It seems like it crops up in the world
> of FPGA/ASIC/chip design, which has all kinds of ill-behaved compilers that
> produce lots of outputs simultaneously.
I would love to see this. However, at present, non-pattern rules and
pattern rules are not consistent in this respect, so I don't see how
to come up with a syntax that is a natural extension of the present.
> I went back and read a bunch of the mailing-list conversations about ways
> it could be implemented, and it seemed like nobody ever proposed a way we
> could describe the syntax in-keeping with GNU Make's conventions.
>
> So I've been chewing on the issue a bit, and I wanted to float this syntax
> proposal:
>
> What about having a special target called .GROUPTARGET, which could work as
> shown below.
>
> --- (sample Makefile) ---
>
> foo1.out report.txt foo2.out foo3.out non_pattern.bit: TASK1_OUTPUTS
> fob1.out static_file.bmm fob2.out fob3.out project_file.ngc: TASK2_OUTPUTS
>
> TASK1_OUTPUTS: source1_a.src source1_b.src
> $(EXTERNAL_UTIL_1) source1_a.src source1_b.src
>
> TASK2_OUTPUTS: source2_a.src source2_b.src
> $(EXTERNAL_UTIL_2) source2_a.src source2_b.src
>
> .GROUPTARGET: TASK1_OUTPUTS TASK2_OUTPUTS
>
> --- (end sample Makefile) ---
>
> In the example above, any dependencies of .GROUPTARGET would be a
> target-group. Each target group could be treated sort of like a conditional
> PHONY that would run if any of the group's members were out-of-date.
>
> What do you think?
To be honest: I think this is a terrible idea, for the same reason
that I consider such special targets to be a terrible idea in
general: their effect is non-local, so it becomes impossible
(undecidable) determine the interpretation of a rule at compile
time in the general case. For instance: a Makefile may generate
and include another Makefile that only includes this special target
(for rules appearing in the first Makefile)
on nights with a full moon.
I would much prefer replacing the normal separator symbol ':'
(in a backwards compatible way).
--
Reinier Post
http://www.win.tue.nl/~rp/