GNU bug report logs - #35848
Should automake use gmake by default if exists?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 35848 in the body.
You can then email your comments to 35848 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: libor.bukata <at> oracle.com
To: bug-automake <at> gnu.org
Subject: Should automake use gmake by default if exists?
Date: Tue, 21 May 2019 15:53:40 +0200

Hi,

automake expects GNU make to support dependency tracking.

On Solaris it works well if MAKE variable is set to gmake during the 
configuration, otherwise, it fails with the following error.

config.status: error: Something went wrong bootstrapping makefile fragments
    for automatic dependency tracking.  Try re-running configure with the
    '--disable-dependency-tracking' option to at least be able to build
    the package (albeit without support for automatic dependency tracking).
See `config.log' for more details

My suggestion is to use gmake by default if the command exists, 
otherwise fallback to make command. It could improve the overall user 
experience since the user would not need to search a solution 
(./configure MAKE=gmake) every-time this error is encountered.

Currently, it seems that the default MAKE value (${MAKE-make}) is 
hard-coded in four m4 files. Would it be possible to set the default 
MAKE value dynamically at the beginning of the configuration phase based 
on the existence of gmake and make commands? The m4 files could then 
expect that MAKE variable is defined from the configure script.

Note that we used automake 1.16.1 on Solaris 11.4 but the issue is also 
reproducible with older automake versions.

Thanks,
Libor

Message #8 received at 35848 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> draconx.ca>
To: libor.bukata <at> oracle.com
Cc: 35848 <at> debbugs.gnu.org
Subject: Re: bug#35848: Should automake use gmake by default if exists?
Date: Tue, 21 May 2019 11:37:22 -0400

On 5/21/19, libor.bukata <at> oracle.com <libor.bukata <at> oracle.com> wrote:
> automake expects GNU make to support dependency tracking.
>
> On Solaris it works well if MAKE variable is set to gmake during the
> configuration, otherwise, it fails with the following error.
>
> config.status: error: Something went wrong bootstrapping makefile fragments
>      for automatic dependency tracking.  Try re-running configure with the
>      '--disable-dependency-tracking' option to at least be able to build
>      the package (albeit without support for automatic dependency
> tracking).
> See `config.log' for more details
>
> My suggestion is to use gmake by default if the command exists,
> otherwise fallback to make command. It could improve the overall user
> experience since the user would not need to search a solution
> (./configure MAKE=gmake) every-time this error is encountered.

I doubt this will actually help users because the user probably
won't know they need to explicitly run "gmake", and if the package
is configured with MAKE=gmake and they run plain "make" it is likely
to also fail.

The only "fancy" feature that Automake's dependency tracking should
require of the make implementation is an "include" functionality, for
example any make which implements the "include" directive from POSIX
should suffice.  I'm pretty sure Solaris make has such a function, so
I'd expect automatic dependency tracking to work with Solaris make.

If it is not working, then there might be a real bug to fix in the
dependency tracking feature in Automake.

> Note that we used automake 1.16.1 on Solaris 11.4 but the issue is also
> reproducible with older automake versions.

This doesn't sound accurate because the error you encountered does not
exist in automake versions before 1.16.  Older versions may have a
/different/ failure, of course...

Cheers,
  Nick

Message #11 received at 35848 <at> debbugs.gnu.org (full text, mbox):

From: libor.bukata <at> oracle.com
To: Nick Bowler <nbowler <at> draconx.ca>
Cc: 35848 <at> debbugs.gnu.org
Subject: Re: bug#35848: Should automake use gmake by default if exists?
Date: Wed, 22 May 2019 10:40:26 +0200

Hi Nick,

On 5/21/19 5:37 PM, Nick Bowler wrote:
> On 5/21/19, libor.bukata <at> oracle.com <libor.bukata <at> oracle.com> wrote:
>> automake expects GNU make to support dependency tracking.
>>
>> On Solaris it works well if MAKE variable is set to gmake during the
>> configuration, otherwise, it fails with the following error.
>>
>> config.status: error: Something went wrong bootstrapping makefile fragments
>>       for automatic dependency tracking.  Try re-running configure with the
>>       '--disable-dependency-tracking' option to at least be able to build
>>       the package (albeit without support for automatic dependency
>> tracking).
>> See `config.log' for more details
>>
>> My suggestion is to use gmake by default if the command exists,
>> otherwise fallback to make command. It could improve the overall user
>> experience since the user would not need to search a solution
>> (./configure MAKE=gmake) every-time this error is encountered.
> I doubt this will actually help users because the user probably
> won't know they need to explicitly run "gmake", and if the package
> is configured with MAKE=gmake and they run plain "make" it is likely
> to also fail.

you are right, the idea would only delay the probable failure, so please 
ignore my original suggestion.

Maybe the error message could be more informative, for example:
Something went wrong during bootstrapping of makefile fragments
for automatic dependency tracking. If the GNU make is not used by
default, consider to rerun the configure script with MAKE="gmake".
You can also try to rerun configure with the '--disable-dependency-tracking'
option to at least be able to build the package (albeit without support
for automatic dependency tracking).

When we agree on wording, I can prepare a patch to update depout.m4 file.

>
> The only "fancy" feature that Automake's dependency tracking should
> require of the make implementation is an "include" functionality, for
> example any make which implements the "include" directive from POSIX
> should suffice.  I'm pretty sure Solaris make has such a function, so
> I'd expect automatic dependency tracking to work with Solaris make.
>
> If it is not working, then there might be a real bug to fix in the
> dependency tracking feature in Automake.

In general, the dependency tracking works on Solaris. However, some 
packages (e.g., jq, flex, graphviz) expect GNU make since Makefile.am 
files are not compatible with Solaris make (conditional assignment 
operator, ...). If it is the case, one would expect a hint to use GNU 
make, therefore, the update of the error message could be the best way 
to go.

Thanks,
Libor

>
>> Note that we used automake 1.16.1 on Solaris 11.4 but the issue is also
>> reproducible with older automake versions.
> This doesn't sound accurate because the error you encountered does not
> exist in automake versions before 1.16.  Older versions may have a
> /different/ failure, of course...
>
> Cheers,
>    Nick

Message #14 received at 35848 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> draconx.ca>
To: libor.bukata <at> oracle.com
Cc: 35848 <at> debbugs.gnu.org
Subject: Re: bug#35848: Should automake use gmake by default if exists?
Date: Wed, 22 May 2019 10:41:05 -0400

Hello,

On 5/22/19, libor.bukata <at> oracle.com <libor.bukata <at> oracle.com> wrote:
> On 5/21/19 5:37 PM, Nick Bowler wrote:
>> On 5/21/19, libor.bukata <at> oracle.com <libor.bukata <at> oracle.com> wrote:
>>> automake expects GNU make to support dependency tracking.
>>>
>>> On Solaris it works well if MAKE variable is set to gmake during the
>>> configuration, otherwise, it fails with the following error.
>>>
>>> config.status: error: Something went wrong bootstrapping makefile
>>> fragments for automatic dependency tracking.  Try re-running configure
>>> with the '--disable-dependency-tracking' option to at least be able to
>>> build the package (albeit without support for automatic dependency
>>> tracking).
>>> See `config.log' for more details
[...]
> In general, the dependency tracking works on Solaris. However, some
> packages (e.g., jq, flex, graphviz) expect GNU make since Makefile.am
> files are not compatible with Solaris make (conditional assignment
> operator, ...). If it is the case, one would expect a hint to use GNU
> make, therefore, the update of the error message could be the best way
> to go.

Oh, now this problem makes sense.

Recent versions of Automake (1.16+) use a make rule to generate the
dependency stubs.  So if the package uses GNU extensions in Makefile.am
then the default "make" might not be able to execute that rule, leading
to this failure to generate the stubs by config.status.

In this case, since those packages require GNU make to work, it would
probably be ideal (short of making their makefiles portable...) if those
packages added a check to their configure scripts that $MAKE supports
whatever extensions are required to build the package.  This would enable
much more accurate error messages (e.g., "$MAKE does not support conditional
assignment required by this package, please try a different make").

But improving this error message is probably a good idea anyway because
I agree "Something went wrong" gives no hint to the user as to what the
problem is.

Cheers,
  Nick

Message #17 received at 35848 <at> debbugs.gnu.org (full text, mbox):

From: libor.bukata <at> oracle.com
To: Nick Bowler <nbowler <at> draconx.ca>
Cc: automake-patches <at> gnu.org, 35848 <at> debbugs.gnu.org
Subject: Re: bug#35848: Should automake use gmake by default if exists?
Date: Thu, 23 May 2019 13:39:19 +0200

[Message part 1 (text/plain, inline)]

Hello,

On 5/22/19 4:41 PM, Nick Bowler wrote:
> Hello,
>
> On 5/22/19, libor.bukata <at> oracle.com <libor.bukata <at> oracle.com> wrote:
>> On 5/21/19 5:37 PM, Nick Bowler wrote:
>>> On 5/21/19, libor.bukata <at> oracle.com <libor.bukata <at> oracle.com> wrote:
>>>> automake expects GNU make to support dependency tracking.
>>>>
>>>> On Solaris it works well if MAKE variable is set to gmake during the
>>>> configuration, otherwise, it fails with the following error.
>>>>
>>>> config.status: error: Something went wrong bootstrapping makefile
>>>> fragments for automatic dependency tracking.  Try re-running configure
>>>> with the '--disable-dependency-tracking' option to at least be able to
>>>> build the package (albeit without support for automatic dependency
>>>> tracking).
>>>> See `config.log' for more details
> [...]
>> In general, the dependency tracking works on Solaris. However, some
>> packages (e.g., jq, flex, graphviz) expect GNU make since Makefile.am
>> files are not compatible with Solaris make (conditional assignment
>> operator, ...). If it is the case, one would expect a hint to use GNU
>> make, therefore, the update of the error message could be the best way
>> to go.
> Oh, now this problem makes sense.
the problem was not clear to me as well until I found the root cause.
>
> Recent versions of Automake (1.16+) use a make rule to generate the
> dependency stubs.  So if the package uses GNU extensions in Makefile.am
> then the default "make" might not be able to execute that rule, leading
> to this failure to generate the stubs by config.status.
Thank you for the explanation, it makes sense.
>
> In this case, since those packages require GNU make to work, it would
> probably be ideal (short of making their makefiles portable...) if those
> packages added a check to their configure scripts that $MAKE supports
> whatever extensions are required to build the package.  This would enable
> much more accurate error messages (e.g., "$MAKE does not support conditional
> assignment required by this package, please try a different make").

A nice idea but I am not sure whether it would work in practice:
1) It assumes that developers know about all the incompatibilities 
between various implementations of make command.
2) Feature-based checking could add lots of tests and increase the 
maintenance cost.
3) GNU make is required by dozens of components and all of them should 
be updated.

Maybe the developer could optionally define a required make 
implementation (does not solve the third bullet).

>
> But improving this error message is probably a good idea anyway because
> I agree "Something went wrong" gives no hint to the user as to what the
> problem is.

I attached a patch that improves the emitted error message if the 
dependency tracking fails. The added hint could help the user to fix the 
configuration error.

Thanks,
Libor

>
> Cheers,
>    Nick

[0001-Improve-the-error-message-when-the-dependency-tracki.patch (text/x-patch, attachment)]

Message #20 received at 35848 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: libor.bukata <at> oracle.com
Cc: nbowler <at> draconx.ca, automake-patches <at> gnu.org, 35848 <at> debbugs.gnu.org
Subject: Re: bug#35848: Should automake use gmake by default if exists?
Date: Fri, 14 Feb 2020 19:39:48 -0700

Hi Libor - back on your improvement to the failed dependency tracking
message, from last May (sorry):

     From: Libor Bukata <libor.bukata <at> oracle.com>
     Date: Thu, 23 May 2019 12:31:31 +0200
     ...
+    AC_MSG_FAILURE([Something went wrong during bootstrapping of makefile
+    fragments for automatic dependency tracking. If the GNU make is not
+    used by default, consider to rerun the configure script with MAKE="gmake".
     ...

I've applied this patch, modulo a few tweaks to the wording. Thanks! -k

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.