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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Jan Beulich writes ("Re: [PATCH] fix qemu building with older make"):
> On 29.07.14 at 15:57, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> >>  # 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?

Oh, I hadn't spotted that amongst the other noise.  I guess that will
do.

> > (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.

RHEL5 was released in March 2007, 11 months after make 3.81 was
released upstream.  Furthermore it is seven years old.  SLES10 was
released in June 2006, and is therefore eight years old.  People refer
to Debian stable as `Debian stale' but frankly this is ridiculous.

At the very least can we put some kind of bound on this ?

How about we `compromise' on the following rule: we will feel
completely entitled to delete any build and tools compatibility code
for anything which was superseded upstream more than a decade ago.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel