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
if MAJOR = 3 then no
else if MAJOR = 4 then
if MINOR = 0 then no
else if MINOR = 1 then no
else if MINOR = 2 then no
else if MINOR = 3 then no
else yes
else yes
> Instead I'm seriously considering something suggested to me by Greg
> McGary, based on Emacs' provide/require (well, I don't know if that's
> where he got the idea but that's what it reminds me of :)), which would
> create a variable like $(.MAKE_FEATURES) containing space-separated
> strings for all the major "enhanced" features that are present in the
> current version of GNU make.
Hm, might work too. In my particular case, the feature I was looking
for was "a correct implementation of the -t option", which I suppose
wouldn't be in such a variable even though -t works in 3.80 and was
horribly broken in 3.79.x.
Perhaps if $(.MAKE_FEATURES) also included a list of this and previous
releases, with exception of releases that never defined
$(.MAKE_FEATURES). That may cause the value to grow excessively long
with time. A possibility would be to document that all v3.xx "feature"
markers (with xx>0) would go away with the introduction of v4.0, so
one could do
ifneq ($(filter version_3.84 version_4.0,$(.MAKE_FEATURES)),)
# Good. We're on 3.84 or later.
# The .FROBNICATE_OPTIONS pseudotarget works here - 3.83 claims
# that it works, but contains minor bugs that happen to kill our
# particular use of it.
else
# Here I am sure that we're on something older than 3.84.
end
--
Henning Makholm "Nemo enim fere saltat sobrius, nisi forte insanit."
_______________________________________________
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
