On 3/30/2010 2:14 AM, Edward Welbourne wrote:
y.tab.h y.tab.c y.output: yacc.ts
I don't actually see that y.output serves any role in this; simply
remove every reference to it and your example should be clearer.
It actually does serve a roll for testing purposes. Try the following
On 3/29/2010 8:20 PM, Philip Guenther wrote:
Hmm. SysV make has offered the desired feature with the syntax
b1 + b2 + b3: d1
touch -r $^ $@
Ah, thank you! I wasn't aware of a precedent syntax for this feature.
I definitely agree with
using this syntax over what I proposed for
On 3/30/2010 2:08 AM, Edward Welbourne wrote:
(While I don't think the sysV syntax is *great*, I personally think
it's a better choice than overloading the meaning of parentheses.)
+1
It also avoids the problem of having to make sense of nesting, e.g.
(b1 (c1 c2)): d1
True,
On 3/31/2010 1:01 AM, tom honermann wrote:
True, but it introduces the problem of making sense of these:
+ b1 + b2 +: d1
b1 + + b2: d1
b1 + b2 b3: d1
Solaris 10 make appears to silently drop dangling and extra '+'
connectors - which is convenient
for handling macros that are empty
On 3/30/2010 11:35 PM, tom honermann wrote:
On 3/29/2010 8:20 PM, Philip Guenther wrote:
Hmm. SysV make has offered the desired feature with the syntax
b1 + b2 + b3: d1
touch -r $^ $@
Ah, thank you! I wasn't aware of a precedent syntax for this
feature. I definitely agree with
y.tab.h y.tab.c y.output: yacc.ts
I don't actually see that y.output serves any role in this; simply
remove every reference to it and your example should be clearer.
y.tab.o: y.tab.c y.tab.h
I don't understand .INTERMEDIATE well enough to know why this chain
fails to lead to y.tab.o's
On 3/3/2010 2:03 AM, Edward Welbourne wrote:
Another possibility crossed my mind over-night, with which I haven't
experimented, but that seems like it theoretically should work.
Replace the touch-file with a phony rule:
yacc.ts: grammar.y
yacc -d -v $^
y.tab.h y.tab.c y.output
On 3/2/2010 5:18 PM, tom honermann wrote:
On 3/2/2010 2:45 AM, Edward Welbourne wrote:
I've been struggling for some time now with how to write rules for
commands that generate multiple targets
A familiar and annoying problem: make really believes in commands that
generate just one
On Mon, Mar 29, 2010 at 7:54 PM, tom honermann tom.honerm...@oracle.com wrote:
Paul, would you be opposed to a patch that implements support for static
multiple target rules using the above syntax?
Any particular concerns or requirements you would have?
...
a1 (b1 b2 b3): d1
touch -r
The only downsides to this I see are:
1: The duplicate file storage. Probably not a big deal.
2: The extra processing time to archive and extract the files. Again,
probably not a big deal.
3: The why'd they do that? questions coming from people unfamiliar
with the technique.
all valid
I've been struggling for some time now with how to write rules for
commands that generate multiple targets
A familiar and annoying problem: make really believes in commands that
generate just one (relevant) file, and doesn't fit so well with ones
that generate several.
The next thing to try
Correcting myself: I missed out the $@ in
y.tab.h y.tab.c y.output: yacc.ts
tar xf $ -m $@
which ensures that each target is the only thing extracted when the
rule to generate it is executed,
Eddy.
___
Bug-make mailing list
@gnu.org] On Behalf Of Edward
Welbourne
Sent: Tuesday, March 02, 2010 02:45
To: tom honermann
Cc: bug-make@gnu.org
Subject: Re: Static multiple target rules
I've been struggling for some time now with how to write rules for
commands that generate multiple targets
A familiar and annoying problem
On 3/2/2010 2:45 AM, Edward Welbourne wrote:
I've been struggling for some time now with how to write rules for
commands that generate multiple targets
A familiar and annoying problem: make really believes in commands that
generate just one (relevant) file, and doesn't fit so well with
14 matches
Mail list logo
