Re: [PATCH] testrun.sh: Implement --tool=strace, --tool=valgrind

[Carlos O'Donell <carlos at redhat dot com>]

On 07/05/2018 06:55 AM, Szabolcs Nagy wrote:
> On 04/07/18 14:22, Carlos O'Donell wrote:
>> On 06/30/2018 09:33 AM, Florian Weimer wrote:
>>> $(file …) appears to be the only convenient way to create files
>>> with newlines and make substitution variables.  This needs make 4.0
>>> (released in 2013), so update the requirement to match.
>>>
>>> 2018-06-30  Florian Weimer  <fweimer@redhat.com>
>>>
>>>     testrun.sh: Implement --tool=strace, --tool=valgrind
>>>     * Makefile (testrun-script): Define variable.
>>>     (testrun.sh): Use variable.
>>>     * manual/install.texi (Tools for Compilation): make 4.0 or later
>>>     is required.
>>>     * configure.ac: Check for make 4.0 or later.
>>>     * INSTALL: Regenerate.
>>>     * configure: Likewise.
>>
>> I'm OK with this. It further enhances the testsuite, and we already
>> require a new enough compiler that make 4.0 should be a NOP for most
>> distributions, with make 4.2.x being used by many.
>>
> 
> this broke my testing on various targets using ubuntu
> 14.04 lts and older debian systems.

Ubuntu 14.04LTS will soon be EOL (10 months).

Ubuntu 16.04LTS or newer has make >= 4.1.

Debian Stretch 9.4 is stable and has make >= 4.1.

Fedora 27 is the oldest non-EOL and has make >= 4.2.

So I don't see this being an issue except with the oldest
Ubuntu 14.04LTS.

I don't think we should revert these changes based on
make availability, unless we see more issues where users
can't upgrade to a newer make for other architectures.

> i will build a new make, but on other projects i prefer
> to stick to 3.82. make 4.0 introduced plugin support and
> other regressions so its behaviour is much less reliable.

You face two issues here.

(a) Obsolescence of your development system.

I empathize with your pain, the base RHEL7 is no longer
capable of compiling glibc, but within RHEL we have a
Developer Toolset with newer binutils, gcc, make, etc. all
which can be used to compile glibc. It still doesn't fix the
kernel headers though, and I have to fetch and use the latest
upstream kernel headers. The glibc team for Red Hat builds on
RHEL7 for release testing and to ensure we could deliver any
new glibc feature if needed by backport (gives us some confidence).

In summary, there will always be some pain here in adopting
newer tooling, but make 4.0 is old enough that newer distributions
should have it.

(b) Reliability issues in make 4.0.

As toolchain developers we should be able to help iron out
robustness issues in GNU Make when we come across them. If
we need a new feature in make 4.0 we should not hesitate to
use it if it enables something newer or more useful, like
it does in this case. Though this kind of enablement should
be tempered against the problems it causes. I personally
haven't seen any issue with make 4.1, and I've been using
it for over 8 months.

-- 
Cheers,
Carlos.