makefiles which require GNU make should be named "GNUmakefile" #214

New Issue

zooko · 2007-11-28T14:26:54Z

zooko commented

2007-11-28 14:26:54 +00:00

If a makefile is named "Makefile" then this indicates to some people that it is written in the POSIX-standard "make" language. If it is instead written in the GNU make language then it should be named "GNUmakefile" so that people know not to try to evaluate it using their non-GNU make tool.

Solaris admins find it irritating to be given a makefile which claims to be compatible with their default make tool but isn't. It smacks of that sort of "pushiness" that is unfortunately common in software development -- something like "We disapprove of people using tools other than ours, so we're going to silently add our extensions into code so that people eventually get tired of encountering our extensions unexpectedly and everyone switches to using our tool exclusively.".

I know that this is really not what Brian meant -- Brian just meant that he is used to typing "M" when he means the makefile -- but I'm afraid it might still give the wrong impression to people who run afoul of it.

The reason I'm raising this issue again is that this morning I noticed another instance of a Solaris admin being irritated by a package which required GNU make but which wasn't documented as requiring GNU make in the README. (This package was not Tahoe, though.)

If a makefile is named "Makefile" then this indicates to some people that it is written in the POSIX-standard "make" language. If it is instead written in the GNU make language then it should be named "GNUmakefile" so that people know not to try to evaluate it using their non-GNU make tool. Solaris admins find it irritating to be given a makefile which claims to be compatible with their default make tool but isn't. It smacks of that sort of "pushiness" that is unfortunately common in software development -- something like "We disapprove of people using tools other than ours, so we're going to silently add our extensions into code so that people eventually get tired of encountering our extensions unexpectedly and everyone switches to using our tool exclusively.". I know that this is really not what Brian meant -- Brian just meant that he is used to typing "M"<TAB> when he means the makefile -- but I'm afraid it might still give the wrong impression to people who run afoul of it. The reason I'm raising this issue again is that this morning I noticed another instance of a Solaris admin being irritated by a package which required GNU make but which wasn't documented as requiring GNU make in the README. (This package was not Tahoe, though.)

zooko added the

labels 2007-11-28 14:26:54 +00:00

warner was assigned by zooko

2007-11-28 14:26:54 +00:00

zooko commented

2007-11-28 20:25:34 +00:00

leaving it up to Brian when if ever to do this

zooko added this to the undecided milestone 2007-11-28 20:25:34 +00:00

warner commented

2008-03-11 01:59:03 +00:00

I've pushed this change. I will experience a 2% productivity hit until my fingers learn to type G instead of M. I would also be interested to hear about the 'make' market share and what percentage of the world is using a non-GNU make. My experience is with sunos/solaris and linux environments, in which either GNU make is the native one, or the native one is so primitive that everybody uses GNU make anyways.

I would prefer to use fewer clevernesses in our makefile. Could someone who has a copy of a non-GNU make tell me what GNU extensions we're using? I don't remember using any when I first wrote it, but I know that a lot of stuff has been added since then..

I've pushed this change. I will experience a 2% productivity hit until my fingers learn to type G<tab> instead of M<tab>. I would also be interested to hear about the 'make' market share and what percentage of the world is using a non-GNU make. My experience is with sunos/solaris and linux environments, in which either GNU make is the native one, or the native one is so primitive that everybody uses GNU make anyways. I would prefer to use fewer clevernesses in our makefile. Could someone who has a copy of a non-GNU make tell me what GNU extensions we're using? I don't remember using any when I first wrote it, but I know that a lot of stuff has been added since then..

warner commented

2008-03-11 02:22:45 +00:00

For reference, the POSIX 'make' specification (perhaps
this?)
does not provide for any conditionals. BSD make added one extension (using
".if"), and GNU make added a different one (using "if"). The Makefiles used
in the GNU project itself (frequently created by the 'automake' tool) use
neither: they are compatible with POSIX make, and implement conditionals with
a hard-to-read series of computed target names and recursive invocations.

So we can choose to forego conditionals, or create a GNU-specific makefile,
or create a BSD-specific makefile.

Zooko and I agreed that our long-term goal is to move as much of the
functionality as we can into setup.py (written in python, using setuptools
plugins where appropriate). Hopefully the Makefile can then just be a visible
way to enumerate which setup.py commands are useful to run (i.e. "test:
setup.py test"), because setup.py --help-commands doesn't always provide
clues as to which commands are actually useful to run. The goal is to remove
enough of the cleverness and complexity from the Makefile that we can afford
to give up the non-POSIX features, thus making it portable to both GNU and
BSD make, and then rename it back to just "Makefile".

For reference, the POSIX 'make' specification (perhaps [this?](http://www.opengroup.org/onlinepubs/009695399/utilities/make.html)) does not provide for any conditionals. BSD make added one extension (using ".if"), and GNU make added a different one (using "if"). The Makefiles used in the GNU project itself (frequently created by the 'automake' tool) use neither: they are compatible with POSIX make, and implement conditionals with a hard-to-read series of computed target names and recursive invocations. So we can choose to forego conditionals, or create a GNU-specific makefile, or create a BSD-specific makefile. Zooko and I agreed that our long-term goal is to move as much of the functionality as we can into setup.py (written in python, using setuptools plugins where appropriate). Hopefully the Makefile can then just be a visible way to enumerate which setup.py commands are useful to run (i.e. "test: setup.py test"), because setup.py --help-commands doesn't always provide clues as to which commands are actually useful to run. The goal is to remove enough of the cleverness and complexity from the Makefile that we can afford to give up the non-POSIX features, thus making it portable to both GNU and BSD make, and then rename it back to just "Makefile".

zooko commented

2008-03-23 01:56:13 +00:00

fixed by changeset:667037a6d60379bd

zooko added the

fixed

label 2008-03-23 01:56:13 +00:00

zooko closed this issue

2008-03-23 01:56:13 +00:00

Sign in to join this conversation.