%% Michael Matz <[EMAIL PROTECTED]> writes:
mm> Ah, right, good idea. Btw. funnily I can't reproduce the effect
mm> of the deferred output on one of the machines even with your
mm> makefile. The child is left running, but the echo "ok done" is
mm> missing, probably because the parent mak
%% Boris Kolpackov <[EMAIL PROTECTED]> writes:
bk> Yes it does. It's not clear to me whether it's good or bad, though.
bk> I don't see how "result depends on how we got here" type of logic
bk> is of any usefulness especially in the context of make (read "build
bk> reproducibility").
bk>
%% James Coleman <[EMAIL PROTECTED]> writes:
jc> Two lines had problems: (see original Makefile and modified one (as in
jc> tgz) below)
jc>$(1): $$($(1)_OBJ) $$($(1)_LIBS:%=-l%)
jc> and
jc> $(LINK.o) $^ $(LDLIBS) -o $@
jc> The first makes e.g. -lpriv and -lprotocol depend
Hello,
8.8 The eval Function has an example of using eval, foreach, ... and I am
planning on using something a bit like that myself. The example provided
has a two problems and I have a fixed version
(tested on GNU Make 3.80 on solaris).
You might like to incorporate this fixed version in the m
Paul,
Paul D. Smith <[EMAIL PROTECTED]> writes:
> I disagree, actually. It's a settled feature of make that the DAG is
> not a simple tree: that there can be more than one pathway to a given
> target in the DAG.
>
> The placement of the .WAIT prerequisite implies a relationship between
> two pre
