[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#35848: Should automake use gmake by default if exists?

From: libor . bukata
Subject: bug#35848: Should automake use gmake by default if exists?
Date: Thu, 23 May 2019 13:39:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1


On 5/22/19 4:41 PM, Nick Bowler wrote:

On 5/22/19, address@hidden <address@hidden> wrote:
On 5/21/19 5:37 PM, Nick Bowler wrote:
On 5/21/19, address@hidden <address@hidden> 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
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.



Attachment: 0001-Improve-the-error-message-when-the-dependency-tracki.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]