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

Previous Next

Full log

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)]

Previous Next

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