GNOME Bugzilla – Bug 785257
JHbuild should not pass global configure options if a module's --help doesn't list them
Last modified: 2017-07-24 01:04:37 UTC
According to https://github.com/cgwalters/build-api, "The configure script MUST either ignore unknown options that start with --enable- and --disable-, or accept an argument --help which prints valid options." JHbuild passes global options like --disable-Werror unconditionally, so this breaks packages (such as SpiderMonkey) that conform to the latter part of the either-or.
In practice, we know any configure script generated by Autoconf is going to ignore the options... I guess SpiderMonkey has its own hand-rolled configure? But if you want to grep the output of --help to make sure the argument is supported before passing it, that's fine by me. It will eliminate annoying warnings about being called with an invalid argument from other packages, too.
Not so easy if there is no configure script yet, e.g. in the case of a clean git checkout of a normal Autotools-conforming module. "./autogen.sh --help" will first run autoreconf and libtoolize and all that stuff. I guess properly we should run autogen.sh with NOCONFIGURE=1 and then run configure, testing any options that are passed automatically to it. But I'll try a simpler patch first...
Created attachment 356156 [details] [review] autotools: Test autogenargs against configure help According to https://github.com/cgwalters/build-api, "The configure script MUST either ignore unknown options that start with --enable- and --disable-, or accept an argument --help which prints valid options." When the given autogen.sh looks like it's a configure script, try running it with --help in order to test whether globally passed autogenargs are supported by the script.
Not wanting to call "autogen.sh --help", this only works in a very few situations; it's enough for SpiderMonkey though.
Review of attachment 356156 [details] [review]: Yeah, this is too specific IMO. If we're going to do this we should do it in a more general way. I'm afraid the next problem we'll run up against is autogen scripts that don't respect the NOCONFIGURE environment variable. I suspect there's going to be way more of these than there will be hand-rolled configure scripts that error out on unexpected arguments. Probably the best thing to do here is just to patch Spidermonkey's configure script to behave sanely and move on.
(In reply to Michael Catanzaro from comment #5) > Probably the best thing to do here > is just to patch Spidermonkey's configure script to behave sanely and move > on. Unfortunately they don't want to do that - https://bugzilla.mozilla.org/show_bug.cgi?id=1379540#c6 An example of commonly used packages that won't accept unknown options are zlib, openssl and libvpx.
We can patch it downstream. Hopefully we never have to build any of that software in JHBuild. :)
> Hopefully we never have to build any of that software in JHBuild. :) I already do, when building GNOME on macOS :-/
How about a supports-unknown-configure-options="no" attribute? Similar to supports-non-srcdir-builds.
Good idea! That's probably the best approach.
Created attachment 356218 [details] [review] autotools: Add supports-unknown-configure-options attribute According to https://github.com/cgwalters/build-api, "The configure script MUST either ignore unknown options that start with --enable- and --disable-, or accept an argument --help which prints valid options." For packages that choose the latter in hand-rolled configure scripts, add a module attribute: supports-unknown-configure-options="no". This is currently used for mozjs, and is also required for building some dependencies on macOS.
Review of attachment 356218 [details] [review]: :(
Attachment 356218 [details] pushed as 0b8f95d - autotools: Add supports-unknown-configure-options attribute