Opened at 2007-11-28T14:26:54Z
Closed at 2008-03-23T01:56:13Z
#214 closed defect (fixed)
makefiles which require GNU make should be named "GNUmakefile"
Reported by: | zooko | Owned by: | warner |
---|---|---|---|
Priority: | trivial | Milestone: | eventually |
Component: | packaging | Version: | 0.7.0 |
Keywords: | Cc: | ||
Launchpad Bug: |
Description
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.)
Change History (4)
comment:1 Changed at 2007-11-28T20:25:34Z by zooko
- Milestone changed from 0.7.1 to undecided
comment:2 Changed at 2008-03-11T01:59:03Z by warner
- Status changed from new to assigned
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..
comment:3 Changed at 2008-03-11T02:22:45Z by warner
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".
comment:4 Changed at 2008-03-23T01:56:13Z by zooko
- Resolution set to fixed
- Status changed from assigned to closed
fixed by 667037a6d60379bd
leaving it up to Brian when if ever to do this