Scripsit Paul D. Smith
> Anyway, you can easily split the current MAKE_VERSION already, like this:
>
> $(subst ., ,$(MAKE_VERSION))
Oops. Major communications foul-up detected. Backtrack to my original
request and change it to:
The existence of $(MAKE_VERSION) should be better documente
%% Henning Makholm <[EMAIL PROTECTED]> writes:
Just FYI, I think those -t problems have been around for a long time;
IIRC I looked as far back as 3.74 and they were there. So just checking
against 3.79% and failing is not going to help...
hm> Scripsit "Paul D. Smith" <[EMAIL PROTECTED]>
>>
Scripsit "Paul D. Smith" <[EMAIL PROTECTED]>
> As for the version numbering, the fact that GNU make is a string-based
> tool and has no numeric operators anyway
Yes, that would be a problem. I think I had in mind something
pedestrian like:
To see whehter this `make' is newer than 4.3, do
I think I'm going to make it 3.81. I'm tired of the extra version on
the end: it orders incorrectly when people look up versions on the FTP
site and too many people pick the older version instead of the newer
one :).
I don't plan on releasing it immediately; I only meant that I planned to
fix it
Scripsit "Paul Smith" <[EMAIL PROTECTED]>
> I've also found another bug: if you use $(eval ...) inside a conditional
> statement it fails! Doh! I'll fix this shortly.
If that means that a release 3.80.1 is planned, would it be possible
to add constant variables $(GNUMAKE_VERSION_MAJOR) and
$(GN
Hi;
After looking at the code I've determined that passing the "o" is not
sufficiently safe. There are sections of the eval() function which call
variable_expand(), which will reset the variable_buffer setup. So if
you put any of those in your expansion text you'll be sad.
So, I'm going with m
%% [EMAIL PROTECTED] (Toomas Rosin) writes:
tr> Well, make's code is not easy to debug (deep recursion), and I
tr> have not done this before. I certainly do not see all the issues
tr> even now, after spending a long and busy day gdb'ing it. I simply
tr> tried to find the simplest working
You <[EMAIL PROTECTED]> wrote:
your post contains some incorrect statements about how and why the
problem occurs, and also incorrect implications for the fix.
Well, make's code is not easy to debug (deep recursion), and I have
not done this before. I certainly do not see all the issues eve
You <[EMAIL PROTECTED]> wrote:
Your fix is not correct; note that the documentation for $(eval ...)
says:
The result of the `eval' function is always the empty string;
thus, it can be placed virtually anywhere in a makefile without
causing syntax errors.
Thus, there is no
Actually, I may have been too abrupt when I said your fix was "not
correct"; I mean, it _is_ not correct in some sense since your post
contains some incorrect statements about how and why the problem occurs,
and also incorrect implications for the fix.
However, the basic idea behind your proposed
%% [EMAIL PROTECTED] (Toomas Rosin) writes:
tr> Given this input:
tr>e0 = $(foreach s,foobar,$(eval $s:))
tr>e0 ==
tr> I certainly did not expect this!
Nevertheless, this one is correct.
tr>e1 == f
tr>e2 == fo
These are indeed incorrect; they should all be like e0
Hello!
Given this input:
f0 = $(foreach s,foobar,$(firstword $s:))
e0 = $(foreach s,foobar,$(eval $s:))
f1 = $(foreach s,foobar, $(firstword $s:))
e1 = $(foreach s,foobar, $(eval $s:))
f2 = $(foreach s,foobar, $(firstword $s:))
e2 = $(foreach s,foobar, $(eval $s:))
all:
12 matches
Mail list logo
