Hello,
On 5/22/19 4:41 PM, Nick Bowler wrote:
Hello,
On 5/22/19, libor.buk...@oracle.com <libor.buk...@oracle.com> wrote:
On 5/21/19 5:37 PM, Nick Bowler wrote:
On 5/21/19, libor.buk...@oracle.com <libor.buk...@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
>From 040f4cc6b8300af4812549d69b07926e5423988a Mon Sep 17 00:00:00 2001
From: Libor Bukata <libor.buk...@oracle.com>
Date: Thu, 23 May 2019 12:31:31 +0200
Subject: [PATCH] Improve the error message when the dependency tracking fails
The dependency tracking may fail with a non-intuitive error
that "Something went wrong ..." if the package expects
GNU make to process its Makefile.am files and other make
implementation is used by default (e.g., Solaris make).
This patch adds a hint to the error message that the user
may try to specify GNU make command as a configure argument.
Related bug with discussion:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35848
* m4/depout.m4: Added a hint to the error message.
---
m4/depout.m4 | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/m4/depout.m4 b/m4/depout.m4
index 431c07d..b8cec38 100644
--- a/m4/depout.m4
+++ b/m4/depout.m4
@@ -38,10 +38,12 @@ AC_DEFUN([_AM_OUTPUT_DEPENDENCY_COMMANDS],
| $MAKE -f - am--depfiles]) || am_rc=$?
done
if test $am_rc -ne 0; then
- AC_MSG_FAILURE([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).])
+ 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".
+ 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).])
fi
AS_UNSET([am_dirpart])
AS_UNSET([am_filepart])
--
1.8.3.1
