GNOME Bugzilla – Bug 742292
jhbuild: figure out how to deal with make vs. gmake
Last modified: 2015-02-01 11:37:27 UTC
Pretty much everything in GNOME depends on being built with GNU make. Some systems install that as 'gmake' (and have 'make' as some other version) and some systems install it as 'make'. We need to figure out a good mechanism to determine which make executable to use, checking if it is GNU make, and invoking it during builds. This also plays into sysdeps because now we generate a virtual package for 'path:make', which is not always appropriate (since sometimes we would want 'path:gmake'). There's also a purity question: do we care about third-party users of jhbuild who are building modules that may not require GNU make and are perfectly happy with whatever system make is available? Do we want to force them to use gmake as well? I'd like to avoid shelling out to 'make -V' on every run, so maybe we could make this based on sysid. Maybe it could be a condition flag? Thoughts welcome.
Autotools tends to build makefiles that require gnu make, so detecting gnu make, setting a variable to point to it, and using that variable for invoking the build phase seems a reasonable thing to do. Other build systems like CMake, distutils, and MakeMaker are generally a lot more liberal and since they're generally not used for Gnome projects we just use whatever make is first in the path for them.
Created attachment 293720 [details] [review] MakeModule: add 'make' helper Instead of repeating the logic in a dozen places, add a helper function that collects arguments, builds the 'make' invocation and executes it. Use this from the autotools and cmake modtypes. There is an inconsistency about whether makeargs are passed to 'make install' between autotools (they aren't) and cmake (they are). This patch preserves that inconsistency.
Created attachment 293721 [details] [review] sysid: add a new 'gmake' condition This condition means that gmake is called 'gmake' on this system. Add a new sysid.get_gmake_cmd() function that returns the name of gmake on this system.
Created attachment 293722 [details] [review] MakeModule: add needs_gmake flag Add a needs_gmake flag for MakeModule. If this is set to True (which is the default for autotools) and the 'gmake' condition is set then the 'gmake' command will be used instead of 'make'. This helps with systems where the system 'make' is not GNU make. This patch effectively establishes an assumption that all autotools packages will require gmake. In the unlikely event that this proves to cause trouble for someone, we could easily add a needs-gmake attribute to the XML to allow people to set it back to 'false'.
Can't we just set MAKE=gmake in the environment on freebsd systems?
My interest here is helping get our supported platforms (which these days surely includes FreeBSD for all of the effort they've been putting into keeping it working) to a point where they can install and use jhbuild without having to write a custom config or set environment variables. That also includes 'jhbuild sysdeps --install' installing the right make and not getting obscure errors part way through the build due to the wrong make. Although it could be argued that modules that depend on gmake ought to verify that in ./configure, it's actually difficult to check there since we don't know which make command the user will call, and it's actually possible to run ./configure without even having make installed at all. I agree that these three patches seem a bit much for the purpose of supporting calling 'gmake' on BSDs, but the biggest one is the first one and it's a net negative that's a nice cleanup that I feel that we should do anyway. After that, the "real" patch here is only a few extra lines.
Created attachment 294838 [details] [review] fixup! MakeModule: add 'make' helper
Attachment 293720 [details] pushed as ed37777 - MakeModule: add 'make' helper Attachment 293721 [details] pushed as 89ebe61 - sysid: add a new 'gmake' condition Attachment 293722 [details] pushed as c597287 - MakeModule: add needs_gmake flag