On 2011-11-22 17:46 +0100, Stefano Lattarini wrote: > On Tuesday 22 November 2011, Nick Bowler wrote: > > This especially includes users who > > have no idea that there's a difference between GNU make and the version > > of "make" that is already on their system. > > Honestly, there are such users today? I mean, almost every Unix newbie > these days either: > > - installs a Linux distro, which comes with GNU make as the default > make program (and we're also ignoring the fact that most such > users will install stuff only through the distro's package manager > anyway, not from sources -- and I don't blame them for this!); > - is using Mac OS X, which comes with GNU make as the default make; > - installs Cygwin (or possibly MinGW/MSYS) or on his Windows system, > thus getting GNU make as the default make in the process. > > I expect a user of the *BSD systems (and even more of proprietay Unixes) > will be learned enough to know the difference between the vendor make and > GNU make.
This is probably true if the user installed such a system on their own PC. But people use computing systems that they did not install themselves, especially with shared systems at schools. At my alma mater, the main computing environment was Solaris (thus "make" was Solaris make rather than GNU make). For many undergrads, this represents their first encounter with unix-like systems. We should strive to make their experiences with free software on those systems a good one! > That said, having some layer that would allow common "make TARGET" commands > to re-invoke themselves with GNU make (maybe with a proper warnings) would > be worthwhile; but this would *not* be done for the benefit of the newbies, > rather to help out the experienced-but-distracted(-or-lazy) user. > > > This is, I think, the single best way to encourage users to become more > > involved in the free software community. If the user can't easily build > > a package, they won't test new versions and they won't test patches. > > Seriously, a user experienced enough to try out a patch will not > have a problem understanding the difference the vendor make and > GNU make, and to act consequently. Maybe so. On the other hand, if you search the web, today, you can easily find instructions on how to apply patches. About as easily as you will find instructions saying to build a package using "./configure && make". Regardless, testing new versions is orthogonal. If the user gives up after failing to build from a release tarball they'll never even get to testing patches. > > (It's truly unfortunate that many popular GNU/Linux distros deliberately > > make this more difficult than it needs to be, but I digress). > > > > I have no doubt that using GNU make will make the the automake > > maintainers' jobs easier. It might even make the jobs of individual > > package maintainers easier. > > See also: > <http://lists.gnu.org/archive/html/automake/2011-01/msg00091.html> Yes, it is sad that many package maintainers fail to properly test their build systems. By the same argument, "GNU-make-requiring automake" is never going to really support GNU make versions older then 3.82 because maintainers won't bother to test with older versions. Regardless, I don't think this is a good reason to force non-portability on those who take the time to test other make implementations. > > But when a user building a free software package for the first time in > > their life runs "./configure && make", and receives a spew of cryptic > > messages about syntax errors or worse, I suspect that their first > > reaction is not going to be "Whoops! I should have run gmake instead." > > More likely it will involve much more colourful language, and they will > > be left with a bitter impression. > > OK. So let's design the new automake to prevent this :-) My above > proposal of "automatic re-execution with GNU make" might help here. > WDYT? It's certainly an option. If we go this route, I think we need, at the very least: * Autoconf tests to find a working GNU make. * Put GNU make logic in GNUmakefile, so that other makes do not try to parse it, and GNU make users don't have to care. * Put stubs in the Makefile for all common targets that will then re-invoke GNU make. * Allow package maintainers to easily define new stubs for their custom targets (bonus points: make this automatic). > > Now, I'm not fundamentally opposed to the idea, but it has to be done > > _right_. > > > Well, yes. And I certainly value the issues you've raised (even if > they are in no way show-stoppers IMHO). We must weigh the costs against the benefits. It's currently not clear to me what the benefits actually are, to anyone other than automake maintainers. Currently, the benefits to automake maintainers is clear, there may be some benefit to package maintainers (hopefully by making automake easier to use), and there seems to be no benefit to users at all. On the other hand, there seems to be a cost from the user's point of view, and there will be an associated cost to package maintainers who now need to educate their users about different make implementations. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
