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
us
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 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/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 comp
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
>>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'
> (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
Eddy.
___
On Mon, Mar 29, 2010 at 7:54 PM, tom honermann 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 $^
evant) file, and doesn't fit so well with ones
that generate several.
And yet, pattern rules do have such support. I'd love to see a syntax
added to enable static
multiple target rules. Since parenthesis are already treated
specially in target names (for archive
rules), perhaps a
makes sense because
gmake has no way of knowing that rebuilding y.output would also
regenerate y.tab.h and y.tab.c. A full solution for static multiple
target rules would recognize that these files had been regenerated and
would also rebuild y.tab.o. But, I think this is good enough for my
u
nd y.tab.c were regenerated). This makes sense because gmake has no
way of knowing that rebuilding y.output would also regenerate y.tab.h
and y.tab.c. A full solution for static multiple target rules would
recognize that these files had been regenerated and would also rebuild
y.tab.o. But, I th
> 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.
al
well with ones
that generate several.
And yet, pattern rules do have such support. I'd love to see a syntax
added to enable static
multiple target rules. Since parenthesis are already treated specially
in target names (for archive
rules), perhaps a syntax like the following could be used w
[mailto:bug-make-bounces+mdorey=bluearc@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 tha
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
Bug-m
> 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 tr
.h -a -f y.tab.c -a -f y.output ] || rm -f yacc.ts)
yacc.ts: grammar.y
yacc -d -v $^
touch $@
y.tab.h y.tab.c y.output: yacc.ts
This works, but is rather inelegant - especially if there are many more
output files than in my simple example. Is there a better way to write
rul
17 matches
Mail list logo
