Require GNU make to build binutils-gdb

Require GNU make to build binutils-gdb

[Simon Marchi]

Hi binutils-gdb folks,

In gdb/, we are now making use of GNU make-specific features (in 
particular, pattern rules), so we now require building with GNU make.  
We based our decision on the fact that, for every platform on which we 
are aware people build GDB on, GNU make is easily available. In fact, 
according to the echoes we got, people already use gmake to build gdb 
everywhere.

Pedro determined that GNU make 3.81 was practically universally 
available:

   https://sourceware.org/ml/gdb-patches/2016-11/msg00475.html

Additionally, CentOS 6 (so probably RHEL6 as well) and Ubuntu 14.04 have 
3.81 in their repos.  Just those two probably represent a significant 
user base.  So, unless we have a really good reason to require something 
more recent, I think it makes sense to require GNU make >= 3.81.

For simplicity and consistency, we were wondering if we should adopt the 
same policy for the whole binutils-gdb tree.  While not necessary, it 
opens up the door to using GNU make-specific constructs in other 
Makefiles in the tree, possibly improving readability and 
maintainability.  This change in GDB gives a good idea:

   http://tinyurl.com/hb8ozrz

There was a discussion in 2014 that spun off another thread.  Nobody 
seemed against the idea, but there was no follow-up AFAICT:

   https://sourceware.org/ml/binutils/2014-05/msg00263.html

In the eventuality this proposition is accepted, should we have a check 
in the top-level Makefile that warns the user early if their version of 
make is not supported?

Simon

Re: Require GNU make to build binutils-gdb

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]

On 17 Nov 2016 14:11, Simon Marchi wrote:
> In gdb/, we are now making use of GNU make-specific features (in 
> particular, pattern rules), so we now require building with GNU make.  
> We based our decision on the fact that, for every platform on which we 
> are aware people build GDB on, GNU make is easily available. In fact, 
> according to the echoes we got, people already use gmake to build gdb 
> everywhere.
> 
> Pedro determined that GNU make 3.81 was practically universally 
> available:
> 
>    https://sourceware.org/ml/gdb-patches/2016-11/msg00475.html
> 
> Additionally, CentOS 6 (so probably RHEL6 as well) and Ubuntu 14.04 have 
> 3.81 in their repos.  Just those two probably represent a significant 
> user base.  So, unless we have a really good reason to require something 
> more recent, I think it makes sense to require GNU make >= 3.81.
> 
> For simplicity and consistency, we were wondering if we should adopt the 
> same policy for the whole binutils-gdb tree.  While not necessary, it 
> opens up the door to using GNU make-specific constructs in other 
> Makefiles in the tree, possibly improving readability and 
> maintainability.  This change in GDB gives a good idea:
> 
>    http://tinyurl.com/hb8ozrz
> 
> There was a discussion in 2014 that spun off another thread.  Nobody 
> seemed against the idea, but there was no follow-up AFAICT:
> 
>    https://sourceware.org/ml/binutils/2014-05/msg00263.html
> 
> In the eventuality this proposition is accepted, should we have a check 
> in the top-level Makefile that warns the user early if their version of 
> make is not supported?

seems like it should be adopted by gcc first ?

for sim/, i have no problem having it follow gdb, although i was planning
on converting it to automake ...
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Require GNU make to build binutils-gdb

[Simon Marchi]

On 2016-11-17 15:06, Mike Frysinger wrote:
>> In the eventuality this proposition is accepted, should we have a 
>> check
>> in the top-level Makefile that warns the user early if their version 
>> of
>> make is not supported?
> 
> seems like it should be adopted by gcc first ?

I am not sure how the management of the top-level files work, so I'll 
let others respond.

But as Andreas Schwab mentioned in our earlier discussions, there is 
already such a check for gcc:

   @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

Since we don't have a particular reason to want 3.81 over 3.80, we could 
just re-use this check (make it unconditional), if that makes it easier.

> for sim/, i have no problem having it follow gdb, although i was 
> planning
> on converting it to automake ...

I think that's a good thing then, automake probably plays better with 
GNU make than other makes.

Re: Require GNU make to build binutils-gdb

[Andreas Schwab]

On Nov 17 2016, Mike Frysinger <vapier@gentoo.org> wrote:

> seems like it should be adopted by gcc first ?

gcc is the forerunner...

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Require GNU make to build binutils-gdb

[Paul Smith]

Regarding the patch linked to earlier, I wonder why multiple pattern
rules were added, rather than just using VPATH plus a few pattern rules
/ explicit rules for the special cases?

I didn't check carefully.


On Thu, 2016-11-17 at 15:33 -0500, Simon Marchi wrote:
> But as Andreas Schwab mentioned in our earlier discussions, there is 
> already such a check for gcc:
> 
>    @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
> 
> Since we don't have a particular reason to want 3.81 over 3.80, we could 
> just re-use this check (make it unconditional), if that makes it easier.

If you want to check for 3.81, you could look for the .FEATURES variable
instead of .VARIABLES; .FEATURES was introduced in 3.81 and is intended
to let your makefile query what features are available without worrying
about specific versions.

It's also never empty, if it exists.  It has one nice advantage in that
it's a static value, while .VARIABLES requires GNU make to create a list
of the names of all the variables.  But, if this check is done early
that's not such a big deal.

3.81 was released 10.5 years ago (Apr 2006).

> > for sim/, i have no problem having it follow gdb, although i was 
> > planning on converting it to automake ...
> 
> I think that's a good thing then, automake probably plays better with 
> GNU make than other makes.

automake, technically, generates POSIX compliant makefiles that don't
rely on GNU make features at all and should work with a wide range of
different make implementations.

At least, that's how it is unless something has changed since I looked
last.

Re: Require GNU make to build binutils-gdb

[Simon Marchi]

On 2016-11-17 15:42, Paul Smith wrote:
> Regarding the patch linked to earlier, I wonder why multiple pattern
> rules were added, rather than just using VPATH plus a few pattern rules
> / explicit rules for the special cases?
> 
> I didn't check carefully.

Are you talking about gdb/Makefile.in?  Could you be more specific?  I 
am not a Makefile expert, so if there's a better way to do what I did, 
I'd like to learn about it.

> If you want to check for 3.81, you could look for the .FEATURES 
> variable
> instead of .VARIABLES; .FEATURES was introduced in 3.81 and is intended
> to let your makefile query what features are available without worrying
> about specific versions.
> 
> It's also never empty, if it exists.  It has one nice advantage in that
> it's a static value, while .VARIABLES requires GNU make to create a 
> list
> of the names of all the variables.  But, if this check is done early
> that's not such a big deal.
> 
> 3.81 was released 10.5 years ago (Apr 2006).

Thanks for the tip.  I found the original gcc patch that added the 3.80 
checking code, it also mentions .FEATURES for checking for 3.81:

   https://gcc.gnu.org/ml/gcc-patches/2008-04/msg01018.html

> automake, technically, generates POSIX compliant makefiles that don't
> rely on GNU make features at all and should work with a wide range of
> different make implementations.
> 
> At least, that's how it is unless something has changed since I looked
> last.

I think you're right. Skimming the automake manual, I saw some mentions 
of tricks you could use if you assumed GNU make would be used.  So in 
the best case, requiring GNU make unlocks some features we could not 
have used otherwise, and worst case it doesn't change anything.

Re: Require GNU make to build binutils-gdb

[Nick Clifton]

Hi Simon,

> In gdb/, we are now making use of GNU make-specific features
> (in particular, pattern rules), so we now require building 
> with GNU make.

> For simplicity and consistency, we were wondering if we should 
> adopt the same policy for the whole binutils-gdb tree.

I think that this is a good idea, although maybe it would be 
helpful to take a two stage approach: for one release (of
binutils) issue an error message if a non-GNU make is used,
but allow a configure option to override this.  (In the same 
way that obsolete targets are currently handled).  Then for 
the release after that make GNU make a hard requirement.

That way we give users a chance to give us feedback if they
are using a non-GNU make and they do not have the option of
changing.

Cheers
  Nick

Re: Require GNU make to build binutils-gdb

[Simon Marchi]

Hi Nick,

On 2016-11-18 05:33, Nick Clifton wrote:
> I think that this is a good idea, although maybe it would be
> helpful to take a two stage approach: for one release (of
> binutils) issue an error message if a non-GNU make is used,
> but allow a configure option to override this.  (In the same
> way that obsolete targets are currently handled).  Then for
> the release after that make GNU make a hard requirement.
> 
> That way we give users a chance to give us feedback if they
> are using a non-GNU make and they do not have the option of
> changing.

That seems fair.  Would you add that check in the top-level Makefile or 
in the binutils/ Makefile?

Simon

Re: Require GNU make to build binutils-gdb

[Nick Clifton]

Hi Simon,

>> I think that this is a good idea, although maybe it would be
>> helpful to take a two stage approach: for one release (of
>> binutils) issue an error message if a non-GNU make is used,
>> but allow a configure option to override this.  (In the same
>> way that obsolete targets are currently handled).  Then for
>> the release after that make GNU make a hard requirement.

> That seems fair.  Would you add that check in the top-level 
> Makefile or in the binutils/ Makefile?

Well, the top-level Makefile is shared with gcc, so we would have
to get approval there as well.  Putting the check in the binutils/
Makefile would certainly be easier, and it should be sufficient
(The only target that I could find that does not build the binutils
sub-directory is the v810, which is not supported as a binutils
target anyway).

Cheers
  Nick

Re: Require GNU make to build binutils-gdb

[Simon Marchi]

On 2016-11-18 12:04, Nick Clifton wrote:
> Well, the top-level Makefile is shared with gcc, so we would have
> to get approval there as well.  Putting the check in the binutils/
> Makefile would certainly be easier, and it should be sufficient
> (The only target that I could find that does not build the binutils
> sub-directory is the v810, which is not supported as a binutils
> target anyway).

Hi Nick,

I tried to prototype putting a check in binutils/Makefile.am, but my 
automake knowledge did not get me very far.  Being one level of 
abstraction above make, it doesn't seem possible at first sight to use 
something like

   ifdef .FEATURES
   $(error "defined")
   else
   $(error "not defined")
   endif

Any idea how to proceed?

Simon