diff mbox

[1/4] Document new hard requirement on GNU make

Message ID 20161116160808.12830-2-simon.marchi@ericsson.com
State New, archived
Headers

Commit Message

Simon Marchi Nov. 16, 2016, 4:08 p.m. UTC 
  From: Simon Marchi <simon.marchi@polymtl.ca>

As discussed in [1], it would be benificial for the GDB project to start
requiring GNU make to build its software.  It would allow using useful
GNU-specific constructs, such as pattern rules.  It would also allow
removing the alternative code paths in the Makefiles (guarded by
GMAKE_TRUE/GMAKE_FALSE), simplifying the Makefile code.

[1] https://sourceware.org/ml/gdb-patches/2016-11/msg00331.html

gdb/ChangeLog:

	* NEWS: Mention requirement of GNU make.
---
 gdb/NEWS | 5 +++++
 1 file changed, 5 insertions(+)

Comments

Eli Zaretskii Nov. 16, 2016, 4:29 p.m. UTC | #1 
> From: Simon Marchi <simon.marchi@ericsson.com>
> CC: Simon Marchi <simon.marchi@polymtl.ca>
> Date: Wed, 16 Nov 2016 11:08:05 -0500
> 
> As discussed in [1], it would be benificial for the GDB project to start
> requiring GNU make to build its software.  It would allow using useful
> GNU-specific constructs, such as pattern rules.  It would also allow
> removing the alternative code paths in the Makefiles (guarded by
> GMAKE_TRUE/GMAKE_FALSE), simplifying the Makefile code.
> 
> [1] https://sourceware.org/ml/gdb-patches/2016-11/msg00331.html
> 
> gdb/ChangeLog:
> 
> 	* NEWS: Mention requirement of GNU make.
> ---
>  gdb/NEWS | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/gdb/NEWS b/gdb/NEWS
> index a6b1282..d76ea81 100644
> --- a/gdb/NEWS
> +++ b/gdb/NEWS
> @@ -11,6 +11,11 @@
>    compiler.  The --disable-build-with-cxx configure option has been
>    removed.
>  
> +* Building GDB and GDBserver now requires GNU make.
> +
> +  It is no longer supported to build GDB or GDBserver with another
> +  implementation of the make program.
> +

OK.

Should we decide which oldest version of GNU Make we are willing to
support?  IOW, which features do we need for the build?

Thanks.
Simon Marchi Nov. 16, 2016, 5:05 p.m. UTC | #2 
On 2016-11-16 11:29, Eli Zaretskii wrote:
> OK.
> 
> Should we decide which oldest version of GNU Make we are willing to
> support?  IOW, which features do we need for the build?
> 
> Thanks.

Probably, yes, but I'm not aware of the exact features/bugfix we have to 
rely on.  From what I can see, pattern rules have been around since 
forever (I checked out a commit of make from 1993, and it was already in 
the doc).  However, if there is a particular bug about pattern rules in 
some versions of make we want to avoid, I am not aware of it.

While trying to make GDBserver use pattern rules as well, I was reading 
this:

   
http://stackoverflow.com/questions/11455182/when-multiple-pattern-rules-match-a-target

I wanted to know which rule would get chosen if you wanted to build 
foo-ipa.o from foo-ipa.c, and you had the two rules:

%.o: %.c
   <generic compilation commands>

%-ipa.o: %-ipa.c
   <ipa-specific compilation commands>

With make >= 3.82, it would do the right thing (choose the second one), 
by choosing the rule with the shorter stem.  Before that, it used the 
order of definition (the first that matches wins).  So it would be nice 
for that reason to require >= 3.82, but it's also possible to work 
around if that's too recent.
Eli Zaretskii Nov. 16, 2016, 5:23 p.m. UTC | #3 
> Date: Wed, 16 Nov 2016 12:05:02 -0500
> From: Simon Marchi <simon.marchi@polymtl.ca>
> Cc: Simon Marchi <simon.marchi@ericsson.com>, gdb-patches@sourceware.org
> 
> > Should we decide which oldest version of GNU Make we are willing to
> > support?  IOW, which features do we need for the build?
> > 
> > Thanks.
> 
> Probably, yes, but I'm not aware of the exact features/bugfix we have to 
> rely on.  From what I can see, pattern rules have been around since 
> forever (I checked out a commit of make from 1993, and it was already in 
> the doc).  However, if there is a particular bug about pattern rules in 
> some versions of make we want to avoid, I am not aware of it.

If all we want to use is pattern rules, then there's no problem.  But
I envision that soon enough we'd want to use more, like
target-specific variables, functions like $(eval) and $(file),
variables like $(MAKE_HOST), etc.

> %.o: %.c
>    <generic compilation commands>
> 
> %-ipa.o: %-ipa.c
>    <ipa-specific compilation commands>
> 
> With make >= 3.82, it would do the right thing (choose the second one), 
> by choosing the rule with the shorter stem.  Before that, it used the 
> order of definition (the first that matches wins).  So it would be nice 
> for that reason to require >= 3.82, but it's also possible to work 
> around if that's too recent.

3.82 shouldn't be a problem, I think.
Simon Marchi Nov. 16, 2016, 10:04 p.m. UTC | #4 
On 2016-11-16 12:23, Eli Zaretskii wrote:
>> With make >= 3.82, it would do the right thing (choose the second 
>> one),
>> by choosing the rule with the shorter stem.  Before that, it used the
>> order of definition (the first that matches wins).  So it would be 
>> nice
>> for that reason to require >= 3.82, but it's also possible to work
>> around if that's too recent.
> 
> 3.82 shouldn't be a problem, I think.

Oops, I said that without even checking the version I have on my system. 
  Ubuntu 14.04, strangely, has make 3.81.  Apparently that was because of 
a critical bug on Debian with 3.82, which stayed open for a long time, 
preventing the upgrade.  Debian and its derivatives, including Ubuntu, 
were stuck with that for a long time.

Refs:
   
http://stackoverflow.com/questions/31912233/how-to-update-make-3-81-linux
   https://lwn.net/Articles/569920/

I don't think it's worth complicating the lives of those users just to 
get the benefit of the behaviour change I mentioned.

So I'm back at having no idea what version we should require.
Pedro Alves Nov. 16, 2016, 11:34 p.m. UTC | #5 
On 11/16/2016 10:04 PM, Simon Marchi wrote:
> On 2016-11-16 12:23, Eli Zaretskii wrote:
>>> With make >= 3.82, it would do the right thing (choose the second one),
>>> by choosing the rule with the shorter stem.  Before that, it used the
>>> order of definition (the first that matches wins).  So it would be nice
>>> for that reason to require >= 3.82, but it's also possible to work
>>> around if that's too recent.
>>
>> 3.82 shouldn't be a problem, I think.
> 
> Oops, I said that without even checking the version I have on my system.
>  Ubuntu 14.04, strangely, has make 3.81.  Apparently that was because of
> a critical bug on Debian with 3.82, which stayed open for a long time,
> preventing the upgrade.  Debian and its derivatives, including Ubuntu,
> were stuck with that for a long time.
> 
> Refs:
>   http://stackoverflow.com/questions/31912233/how-to-update-make-3-81-linux
>   https://lwn.net/Articles/569920/
> 
> I don't think it's worth complicating the lives of those users just to
> get the benefit of the behaviour change I mentioned.
> 
> So I'm back at having no idea what version we should require.

I think we should go with the same requirement as gcc (3.80), as
seen on the top level Makefile.in:

@if gcc
ifeq (,$(.VARIABLES)) # The variable .VARIABLES, new with 3.80, is never
empty.
$(error GNU make version 3.80 or newer is required.)
endif
@endif gcc

... and listed on their prerequisites page:

  https://gcc.gnu.org/install/prerequisites.html

(I'd be very nice to have a page like that for gdb.  Currently
we're not very organized wrt to prerequisite tracking.)

Thanks,
Pedro Alves
Eli Zaretskii Nov. 17, 2016, 3:34 a.m. UTC | #6 
> Date: Wed, 16 Nov 2016 17:04:59 -0500
> From: Simon Marchi <simon.marchi@polymtl.ca>
> Cc: gdb-patches@sourceware.org
> 
> > 3.82 shouldn't be a problem, I think.
> 
> Oops, I said that without even checking the version I have on my system. 
>   Ubuntu 14.04, strangely, has make 3.81.  Apparently that was because of 
> a critical bug on Debian with 3.82, which stayed open for a long time, 
> preventing the upgrade.  Debian and its derivatives, including Ubuntu, 
> were stuck with that for a long time.
> 
> Refs:
>    
> http://stackoverflow.com/questions/31912233/how-to-update-make-3-81-linux
>    https://lwn.net/Articles/569920/
> 
> I don't think it's worth complicating the lives of those users just to 
> get the benefit of the behaviour change I mentioned.
> 
> So I'm back at having no idea what version we should require.

I guess that'd be 3.81, then.
Jonas Maebe Nov. 17, 2016, 10:05 a.m. UTC | #7 
Eli Zaretskii wrote on Thu, 17 Nov 2016:

>> Date: Wed, 16 Nov 2016 17:04:59 -0500
>> From: Simon Marchi <simon.marchi@polymtl.ca>
>> Cc: gdb-patches@sourceware.org
>>
>> So I'm back at having no idea what version we should require.
>
> I guess that'd be 3.81, then.

(Mac) OS X/macOS also ships with 3.81. Although that one will  
presumably never be updated to anything newer due to the switch to  
GPLv3, so it may not make sense to limit yourself based on that.


Jonas
Pedro Alves Nov. 17, 2016, 12:39 p.m. UTC | #8 
On 11/16/2016 11:34 PM, Pedro Alves wrote:
> On 11/16/2016 10:04 PM, Simon Marchi wrote:
>> On 2016-11-16 12:23, Eli Zaretskii wrote:
>>>> With make >= 3.82, it would do the right thing (choose the second one),
>>>> by choosing the rule with the shorter stem.  Before that, it used the
>>>> order of definition (the first that matches wins).  So it would be nice
>>>> for that reason to require >= 3.82, but it's also possible to work
>>>> around if that's too recent.
>>>
>>> 3.82 shouldn't be a problem, I think.
>>
>> Oops, I said that without even checking the version I have on my system.
>>  Ubuntu 14.04, strangely, has make 3.81.  Apparently that was because of
>> a critical bug on Debian with 3.82, which stayed open for a long time,
>> preventing the upgrade.  Debian and its derivatives, including Ubuntu,
>> were stuck with that for a long time.
>>
>> Refs:
>>   http://stackoverflow.com/questions/31912233/how-to-update-make-3-81-linux
>>   https://lwn.net/Articles/569920/
>>
>> I don't think it's worth complicating the lives of those users just to
>> get the benefit of the behaviour change I mentioned.
>>
>> So I'm back at having no idea what version we should require.
> 
> I think we should go with the same requirement as gcc (3.80), as
> seen on the top level Makefile.in:
> 
> @if gcc
> ifeq (,$(.VARIABLES)) # The variable .VARIABLES, new with 3.80, is never
> empty.
> $(error GNU make version 3.80 or newer is required.)
> endif
> @endif gcc

Actually, I take that back.  I was just using "makes it easier
to have a single top level check", but that's not really a good
rationale.  I wouldn't want to be stuck if gcc decides to
move at a glacial pace.

Probably a policy similar to the C++NN one makes more sense.

I see now that 3.81 was released in 2006, so should not be
a problem to require it.

OOC, I wrote a quick&dirty script (attached) to check for GNU Make
availability in the GCC compile farm.  It tries all gcc*.fsffrance.org
from 1 to 250.  I don't have access to all machines setup, as some are
multiplexed on a single IP with different ports, requiring tweaking
the local ssh config.  However, what I found was already interesting,
I believe.  Here's the result:

Number of accessible hostnames: 66
Number of inaccessible hostnames: 184
Hostnames with GNU Make: 66
Hostnames without GNU Make: 0
Distribution: 
     56 GNU Make 3.81
      2 GNU Make 3.82
      7 GNU Make 4.0
      1 GNU Make 4.1
Unique hosts with GNU Make: 20          
Unique hosts without GNU Make: 0
Distribution: 
     10 GNU Make 3.81
      2 GNU Make 3.82
      7 GNU Make 4.0
      1 GNU Make 4.1

I.e., I didn't find a single machine still stuck with GNU Make 3.80.

Thanks,
Pedro Alves
#!/bin/bash

rm -f make-ver.gcc*.fsffrance.org

function kill_ssh() {
    ps | grep ssh | awk '{print $1}' | xargs kill
}

function ctrl_c() {
    kill_ssh
}

trap ctrl_c INT

function do_ssh() {
    cmd="sh -c '[ -f /etc/os-release ] && cat /etc/os-release; printf \"hostname: \"; hostname; printf \"uname: \"; uname -a; ((make -v 2>&1 | grep -q GNU) && make -v) || ((gmake -v 2>&1 | grep -q GNU) && gmake -v)' 2>&1"

    # Retry 5 times, wait 5 seconds between attempts.
    for i in {1..5}
    do
	ssh -q -o UserKnownHostsFile=/dev/null -oStrictHostKeyChecking=no -oBatchMode=yes gcc$h.fsffrance.org "$cmd" >make-ver.gcc$h.fsffrance.org 2>&1 && break || sleep 5;
    done
}

for h in `seq 1 250`
do
    do_ssh &
done

echo "waiting 30s..."
sleep 30
kill_ssh

# Move inaccessible hosts out of the way.
mkdir -p nohost
find . -maxdepth 1 -size 0 | while read line; do mv $line nohost/; done
grep -l "Network is unreachable" make-ver.gcc* | while read line; do mv $line nohost/; done
grep -l "Connection timed out" make-ver.gcc* | while read line; do mv $line nohost/; done
grep -l "Permission denied" make-ver.gcc* | while read line; do mv $line nohost/; done
grep -l "Could not resolve hostname" make-ver.gcc* | while read line; do mv $line nohost/; done
grep -l "Connection refused" make-ver.gcc* | while read line; do mv $line nohost/; done

printf "Number of accessible hostnames: "
ls make-ver.gcc* | wc -l

printf "Number of inaccessible hostnames: "
ls nohost/make-ver.gcc* | wc -l

printf "Hostnames with GNU Make: "
grep -l "GNU Make" make-ver.gcc* | wc -l

printf "Hostnames without GNU Make: "
grep -L "GNU Make" make-ver.gcc* | wc -l

echo "Distribution: "
grep -h "GNU Make" make-ver.gcc* | sort | uniq -c

# Kill dups (found via uname in the ssh command)
(fdupes -f . | grep -v '^$' | xargs rm -v)2>&1 >/dev/null

printf "Unique hosts with GNU Make: "
grep -l "GNU Make" make-ver.gcc* | wc -l

printf "Unique hosts without GNU Make: "
grep -L "GNU Make" make-ver.gcc* | wc -l

echo "Distribution: "
grep -h "GNU Make" make-ver.gcc* | sort | uniq -c
Pedro Alves Nov. 17, 2016, 12:43 p.m. UTC | #9 
On 11/17/2016 10:05 AM, Jonas Maebe wrote:
> 
> Eli Zaretskii wrote on Thu, 17 Nov 2016:
> 
>>> Date: Wed, 16 Nov 2016 17:04:59 -0500
>>> From: Simon Marchi <simon.marchi@polymtl.ca>
>>> Cc: gdb-patches@sourceware.org
>>>
>>> So I'm back at having no idea what version we should require.
>>
>> I guess that'd be 3.81, then.
> 
> (Mac) OS X/macOS also ships with 3.81. Although that one will presumably
> never be updated to anything newer due to the switch to GPLv3, so it may
> not make sense to limit yourself based on that.

I believe https://www.macports.org/ should make it easy to install
whatever newer dependency than what ships built in with the OS.
(I don't use MacOS, though.)  According to:

 https://trac.macports.org/browser/trunk/dports/devel/gmake/Portfile

they have 4.1 available.

So I think macOS wouldn't be a problem if we wanted to require
something newer.

Thanks,
Pedro Alves
Simon Marchi Nov. 17, 2016, 1:38 p.m. UTC | #10 
On 2016-11-17 07:39, Pedro Alves wrote:
> Actually, I take that back.  I was just using "makes it easier
> to have a single top level check", but that's not really a good
> rationale.  I wouldn't want to be stuck if gcc decides to
> move at a glacial pace.
> 
> Probably a policy similar to the C++NN one makes more sense.
> 
> I see now that 3.81 was released in 2006, so should not be
> a problem to require it.
> 
> OOC, I wrote a quick&dirty script (attached) to check for GNU Make
> availability in the GCC compile farm.  It tries all gcc*.fsffrance.org
> from 1 to 250.  I don't have access to all machines setup, as some are
> multiplexed on a single IP with different ports, requiring tweaking
> the local ssh config.  However, what I found was already interesting,
> I believe.  Here's the result:
> 
> Number of accessible hostnames: 66
> Number of inaccessible hostnames: 184
> Hostnames with GNU Make: 66
> Hostnames without GNU Make: 0
> Distribution:
>      56 GNU Make 3.81
>       2 GNU Make 3.82
>       7 GNU Make 4.0
>       1 GNU Make 4.1
> Unique hosts with GNU Make: 20
> Unique hosts without GNU Make: 0
> Distribution:
>      10 GNU Make 3.81
>       2 GNU Make 3.82
>       7 GNU Make 4.0
>       1 GNU Make 4.1
> 
> I.e., I didn't find a single machine still stuck with GNU Make 3.80.
> 
> Thanks,
> Pedro Alves

Thanks for doing this!  That, gives us some data on which to base 
ourselves to require make 3.81.

Eli, I would update the NEWS entry to:

   * Building GDB and GDBserver now requires GNU make >= 3.81.

     It is no longer supported to build GDB or GDBserver with another
     implementation of the make program or en earlier GNU make version.

Does it look good to you?

Where else should that dependency be documented?
Eli Zaretskii Nov. 17, 2016, 4:10 p.m. UTC | #11 
> Date: Thu, 17 Nov 2016 08:38:47 -0500
> From: Simon Marchi <simon.marchi@polymtl.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sourceware.org
> 
> Eli, I would update the NEWS entry to:
> 
>    * Building GDB and GDBserver now requires GNU make >= 3.81.
> 
>      It is no longer supported to build GDB or GDBserver with another
>      implementation of the make program or en earlier GNU make version.
> 
> Does it look good to you?

Yes, thanks.

> Where else should that dependency be documented?

On the wiki, perhaps?
diff mbox

Patch

diff --git a/gdb/NEWS b/gdb/NEWS
index a6b1282..d76ea81 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -11,6 +11,11 @@ 
   compiler.  The --disable-build-with-cxx configure option has been
   removed.
 
+* Building GDB and GDBserver now requires GNU make.
+
+  It is no longer supported to build GDB or GDBserver with another
+  implementation of the make program.
+
 * Native debugging on MS-Windows supports command-line redirection
 
   Command-line arguments used for starting programs on MS-Windows can