Re: Could automake-generated Makefiles required GNU make? (was: Re: [gnu-prog-discuss] portability)

[Dave Hart]

On Tue, Nov 22, 2011 at 16:46, Stefano Lattarini
<address@hidden> 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