On Wed, Nov 23, 2011 at 02:24, Warren Young <war...@etr-usa.com> wrote: > Google just found this for me in the NetBSD docs: "Packages which use GNU > Automake will almost certainly require GNU Make." I'm guessing that was > written by a NetBSD fan from experience, rather than slipped in by some > pro-GNU-anti-BSD saboteur. If so, fait accompli already.
Not so fast. The advice is not bad but it's howto-style advice based on the fact that many packages built using Automake are only tested by their maintainers and vocal users with 'make' being GNU make. It does not state and shouldn't be read to imply that GNU Automake requires GNU make of the tarball user. When testing NTP build compatibility, I use the 'make' the system provides, even if gmake is available, because I want to know of portability problems to other makes and because the instructions are "configure && make" not "configure && (gmake || make)". Unfortunately, I know others say "I prefer GNU make" and translate that into "I test NTP build compatibility only after ensuring make/$MAKE points to GNU make on every one". The latter practice hides portability problems that will arise for users unaware they are expected to similarly prefer GNU make and prearrange to ensure make or $MAKE leads to it. > Besides, why should BSD purity get to hold back the Autotools? If the > distrowatch.com stats are to be believed, *BSD's market share is under 1% > that of Linux, which itself is only about 1% of the overall market of > machines the Autotools can reasonably be used on. Further reduce that by > the percentage of BSD boxes that have not yet had gmake installed after > installation; 10% maybe? We're probably talking about a set of boxes > comprising < 0.001% of the market. (10% of 1% of 1%.) If Autotools are primarily intended to support those using GNU/Linux systems and portability is not a goal, your argument that GNU has won and BSD compatibility of free software is no longer worthwhile makes sense. As long as build system portability is a goal, the numbers don't really matter until no one using Autotools has any customers they want to support using non-GNU/Linux systems. As Ralf suggests, Automake has made it this far without requiring more than portable make. Changing to producing tarballs which require the end user provide GNU make before they will build means increased end-user pain on non-GNU/Linux systems to reduce Automake maintainer pain and pain of developers creating packages with Automake. There are tradeoffs and it brings up the myriad ways Automake is used in the wild, not always in purely free software scenarios and not only by developers. Automake-produced makefiles are used by end users building from source with no interest in developing software. Cheers, Dave Hart