This is the mail archive of the
automake@gnu.org
mailing list for the automake project.
Re: proposal to fork the build-tools projects
- From: "Paul D. Smith" <psmith at gnu dot org>
- To: tromey at redhat dot com
- Cc: Tom Lord <lord at regexps dot com>, Automake List <automake at gnu dot org>
- Date: 24 Oct 2002 18:50:42 -0400
- Subject: Re: proposal to fork the build-tools projects
- Organization: GNU's Not Unix!
- References: <Pine.LNX.4.44.0210152108580.928-100000@localhost.localdomain><200210162124.OAA03641@morrowfield.regexps.com><87n0p99bhu.fsf@fleche.redhat.com><200210210647.XAA25967@morrowfield.regexps.com><200210210803.BAA26196@morrowfield.regexps.com><87wuo74he6.fsf@fleche.redhat.com>
- Reply-to: psmith at gnu dot org
%% Tom Tromey <tromey@redhat.com> writes:
Tom> If you do things right, your Makefiles don't need to contain
Tom> specific filenames at all, and you don't need to edit any
Tom> Makefiles as you add, delete, or rename files
tom> Long-time automake readers already know I'm strongly against this
tom> sort of structuring.
I agree. Explicit lists of files are the way to go. Everywhere I've
seen globbing used it's been much more hassle than it was worth.
tom> All implementations of make, including GNU make, are missing
tom> features that are helpful when scaling up to larger builds. They
tom> are also missing features which help dependability and
tom> reproducibility of builds. In some cases, like using timestamps
tom> instead of signatures, this change is impossible to implement in
tom> make -- switching to signatures would break every Makefile that
tom> uses a stamp file.
I would never argue that make is the world's greatest build tool, or
that there aren't many reasons to ditch it, but I don't think using
signatures is one of them. It's quite trivial (conceptually) to provide
special targets or whatever that allow you to choose an alternative
"out-of-dateness" test than the traditional timestamp comparison.
I agree that depending on the code it might not be so trivial to
implement (in GNU make, for example, the code that determines
out-of-dateness is not quite so clean as one might hope--nevertheless
it's still quite doable I'm sure).
IMO a larger hurdle (from an implementation point of view) is moving
from make's current completely stateless existence into the kind of
stateful world required by other comparison methods such as signatures.
There are lots of "database" issues to examine there.
--
-------------------------------------------------------------------------------
Paul D. Smith <psmith@gnu.org> Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist