bug#35848: Should automake use gmake by default if exists?
| Newsgroups | gmane.comp.sysutils.automake.bugs,gmane.comp.sysutils.automake.patches |
|---|---|
| Organization | Oracle Corporation |
| Message-ID | <[email protected]> |
Hello, On 5/22/19 4:41 PM, Nick Bowler wrote: > Hello, > > On 5/22/19, [email protected] <[email protected]> wrote: >> On 5/21/19 5:37 PM, Nick Bowler wrote: >>> On 5/21/19, [email protected] <[email protected]> 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, 1.8 KB)
From 040f4cc6b8300af4812549d69b07926e5423988a Mon Sep 17 00:00:00 2001 From: Libor Bukata <[email protected]> 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