[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] fix qemu building with older make

>>> On 29.07.14 at 15:57, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> Jan Beulich writes ("[PATCH] fix qemu building with older make"):
>> The $(or ) builtin (uses introduced by commits ffbf089357 and
>> 8962a8f951) is supported only from make 3.81 onwards, yet we claim to
>> only require make 3.80. Introduce a good enough fallback.
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> --- a/Config.mk
>> +++ b/Config.mk
>> @@ -12,6 +12,7 @@ space   := $(empty) $(empty)
>>  # fallback for older make
>>  realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && 
>> echo "$$PWD/$(notdir $(file))")))
>> +or       = $(if $(strip $(1)),$(1),$(if $(strip $(2)),$(2),$(if $(strip 
>> $(3)),$(3),$(if $(strip $(4)),$(4)))))
> Can we (a) have a comment here explaining why

To me the "fallback for older make" comment is enough of answering
the "why" part. What else do you want?

> (b) have some kind of
> time limit on how long we need to support make 3.80 ?
> 3.81 was released upstream over eight years ago in April 2006.

I know, but I also know there's going to be a few more years where
for my day-to-day work SLE10 (coming with make 3.80) is the lowest
common denominator in order to be able to test backports there.
And RHEL5, iirc released at about the same time, was also quite
recently considered a platform desirable to continue to support.

Of course I'm having my own, self-built newer make versions around,
so as far as make is concerned I could live with that compatibility
requirement dropped (leaving aside that tying the resulting build
failure when inadvertently using the older make to the missing
support for a particular builtin isn't straightforward). But there are
other old package versions we still support (like Python 2.4) for that
same reason, and I can't see myself using self-built replacements of
all those as well.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.