On Tue, Nov 22, 2011 at 16:46, Stefano Lattarini <stefano.lattar...@gmail.com> wrote: > On Tuesday 22 November 2011, Nick Bowler wrote: >> I think this discussion is for the most part ignoring what is (IMO) the >> most important issue: it must be easy for ordinary (non-developer) users >> to build free software packages!
Hear, hear! My selfish agenda is to keep even the most ancient and crusty systems able to build NTP tarballs with the minimum of prerequisites. This is why when sntp started using libevent, we worked with the libevent maintainers to upstream changes to it making it more suitable for source-level inclusion in dependent packages, and we now have libevent in every NTP tarball. If you have a suitably-recent libevent installed, great, we use it, otherwise we build our tearoff libevent as a static library and link against it. Such a path is not feasible for GNU make. If our distributions require GNU make, we will be at the mercy of Automire/Automake 2 in terms of finding and using existing GNU make when it is not called "make". Stefano has previously indicated packages which want to remain as portable as possible could stick with Automake 1.x for at least several years before Automake 1.x is no longer maintained in favor of Automire/Automake 2, but no one likes to be stuck on a dead-end train. If you draw Automake maintainers' focus to Automake 2, you simultaneously send a strong message that Automake 1.x is on its way out, and will invite legitimate concerns about every future Automake 1.x's quality given the cool kids among the maintainers have all switched focus to Automake 2.x. Calling your Automake fork requiring GNU make of tarball users Automire is much less dangerous to the Automake brand, and it sends the message that the branch we're calling Automake 1.x here, which targets portable make, is not necessarily doomed to lack of maintenance within a few years. >> 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. > > 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. Nick has already made this point pretty well, but I want to toss my voice behind his: Stefano's mental model of who might not already be using GNU make or understand the difference between portable make and GNU make is overly restrictive and doesn't admit scenarios important to me in my quest to keep NTP tarballs buildable by as many people as possible, including those whose 'make' is not GNU and those who would have to build GNU make from source to have it available. "newbies" aren't the only concern here -- there are plenty of people using Automake-supported systems without the slightest developer skills -- they are interested in using software, not changing or writing software, in some cases. They are "newbies" to Makefiles and build infrastructure engineering for years after they are productive sticking to their packages and ports systems. When I ask them to see if a problem they're having with their ntpd exists in currently-maintained versions, they might never have built any software from source, and they may not be using a system that ships GNU make. I am talking about tarball users, not developers. I want to keep the barrier as low as I can. It is not acceptable to me to assume they are naturally on their way to being software developers simply because they are using a GNU-like system. Similarly it is not true that nearly all such 'newbies' in the last few years are using Linux or Mac OS. In the last few years, people who have reason to build ntpd from source whom I've encountered have been as likely to be using proprietary or BSD OS than Linux or Mac OS. In my world, it is not only old hands stuck in their ways and well-versed in BSD make vs. GNU make who are users of BSD and proprietary OSes. Sometimes someone else chose the OS they use (university administrator, company IT guy). Sometimes they have license-related influence on that choice, where to be ethical they are forced to avoid building on GPL technologies and seek BSD-licensed alternatives. OS choices aren't always a matter of popularity or preference. Automake is GNU software that, like several other pieces of GNU build infrastructure, has enhanced portability of a lot of software. As pointed out previously, before decreasing portability of packages relying on Automake, we should consider the perspective of end users of all sorts of Automake-using packages, weighing the benefits to them against the cost of requiring GNU make before "configure && make" (or gmake...) I like RMS's idea of switching one or two GNU packages to require GNU make to test the waters. Obviously, GNU make itself needs to require only portable make to enable bootstrapping. I agree the experiment shouldn't be done first with Automake, as that would have implications for all packages uses Automake. Doing it with an Automake fork called Automire wouldn't be such a problem, but Stefano probably doesn't find forking appealing for a number of sound reasons. Thanks for the choice to support use of Automake by non-GPL packages, and for hearing the concerns of a maintainer of such a package. Cheers, Dave Hart
