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

Previous Next

Package: automake;

Reported by: libor.bukata <at> oracle.com

Date: Tue, 21 May 2019 14:31:01 UTC

Severity: normal

Done: Karl Berry <karl <at> freefriends.org>

Bug is archived. No further changes may be made.

Full log


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




This bug report was last modified 5 years and 156 days ago.

Previous Next


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