%% Dan Jacobson <[EMAIL PROTECTED]> writes:
dj> Anyways,
dj> $ make x& make y& wait
dj> cannot always be rewritten with -j.
Mm. I don't think I believe that. For example, of your makefile had at
the top:
.PHONY: all rx ry
all: rx ry
rx: ; $(MAKE) x
ry: ; $(MAKE) y
then
Dan Jacobson wrote:
Anyways,
$ make x& make y& wait
cannot always be rewritten with -j.
$ make -j[whatever number] x y
will act differently except for special cases of x and y;
probably when both x and y have no dependencies.
make x& make y& wait
will only work correctly if x and y have no depend
Dan Jacobson wrote:
Anyways,
$ make x& make y& wait
cannot always be rewritten with -j.
$ make -j[whatever number] x y
will act differently except for special cases of x and y;
probably when both x and y have no dependencies.
Anyways, with -j examples added to the manual, we would get on the
right
Anyways,
$ make x& make y& wait
cannot always be rewritten with -j.
$ make -j[whatever number] x y
will act differently except for special cases of x and y;
probably when both x and y have no dependencies.
Anyways, with -j examples added to the manual, we would get on the
right track about how to
%% Pierre B <[EMAIL PROTECTED]> writes:
pb> The problem is with the backquote AND/OR addprefix.
pb> The following makefile illustrates the bug.
I think you're misunderstanding something basic here.
Make does not process backquotes. The shell processes backquotes. Make
only processes functi
The problem is with the backquote AND/OR addprefix.
The following makefile illustrates the bug.
Notice the doubled ././ in the test output.
Version information is in the output.
#
# Make file illustrates a problem with back quote
# by juxtaposing results with back quote and shell
#
#
nice_string:=$
Paul D. Smith <[EMAIL PROTECTED]> writes:
> If it is a bug then what you say is true, but I have never termed it a
> bug. It was a design decision taken between two alternative
> implementations, and the code is operating the way it was designed and
> intended to work.
I don't believe you ever
%% Boris Kolpackov <[EMAIL PROTECTED]> writes:
bk> "Paul D. Smith" <[EMAIL PROTECTED]> writes:
id> Ok, but I am surprised you don't you see any problem (bug) with
id> the current way?
>> Not really. The times where it makes any difference are very few,
bk> I don't think the presence o
"Paul D. Smith" <[EMAIL PROTECTED]> writes:
> id> Ok, but I am surprised you don't you see any problem (bug) with
> id> the current way?
>
> Not really. The times where it makes any difference are very few,
I don't think the presence of the bug is in any way affected by the number
of situat
%% "Ian Dunbar" <[EMAIL PROTECTED]> writes:
id> Ok, but I am surprised you don't you see any problem (bug) with
id> the current way?
Not really. The times where it makes any difference are very few, and
the performance penalty that would be incurred to re-invoke make after
each makefile was
Hi Paul,
Thanks for the clarification. I have still some questions though.
From: "Paul D. Smith" <[EMAIL PROTECTED]>
id> It would know that the order of making up to date has to be:
id> Makefile, sub.mk, subsub.mk, subsubsub.mk, etc., because if sub.mk
id> is out of date, there is no guarente
11 matches
Mail list logo
