[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: Nick Bowler
Subject: bug#35848: Should automake use gmake by default if exists?
Date: Wed, 22 May 2019 10:41:05 -0400


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
>>> 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.


reply via email to

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