Re: proposal to fork the build-tools projects

[Tom Lord]

       Long-time automake readers already know I'm strongly against
       this sort of structuring.  This yields Makefiles which are
       fragile and undependable.  For instance, if you create a
       temporary file with a "source-like" name in the source tree,
       then the build fails.


Conversely, using the opposite approach, if you add a source file, and
fail to correctly update the makefile, the build fails.  Big whoop.
Just as "fragile and undependable" either way.  This is a purely
rhetorical line of analysis that admits no objective decision making.




        There was a brief time where I vacillated, if you read the
        archives fully.

It's a fuzzy area.  There's apparently no a priori line of reasoning
that clearly decides the issue.  Agreed?

My experience with a globbing based system goes back about 15 years.
15 years ago, I learned this approach from a prolific community of
hackers who had used it happily for about 5 years previous.  It's just
more practical, in our experience, even if theoretically weird; sort
of like even temperament.

But it doesn't matter -- I don't intend to decide this one minor issue
in this particular thread.



        All implementations of make, including GNU make, are missing features
        that are helpful when scaling up to larger builds.  They are also
        missing features which help dependability and reproducibility of
        builds.  In some cases, like using timestamps instead of signatures,
        this change is impossible to implement in make -- switching to
        signatures would break every Makefile that uses a stamp file.

        For this and other reasons I think that make must go.

For the purposes of the fork the build tools discussion, I'm not
disagreeing.   Perhaps make should go, perhaps not.  If it stays, I'd
sure like some cleanups.

Mostly what I want is to reach a state where, instead of writing
makefiles, I just declare a directory's "type" from the construction
perspective.  As in: these are modules for libhackerlab;  or, unless
otherwise specified, these are `main' modules of $x/bin programs.
With `make', the ideal is a series of `include' directives with,
perhaps, one or two variable declarations preceeding.

Explicit file lists vs. globbing?  Eh...that's a comparatively minor
issue.

Getting rid of make -- or making a better make -- or making a trivial
make with a better front end -- any of these sound like reasonable
ways to proceed.   They are certainly design space directions to give
serious consideration to.   I hope we don't decide them by trying to
out-butch one another on mailing lists though  --  I hope we do a
proper design space search and look for concensus over the
_implications_ of these questions for the final design, rather than
over bullshit arguments on a mailing list.  You know, almost as if it
were an R&D project.

But just to pick up on what you seem to be implying when you say "make
must go":

Bootstrapping is an issue.  Even if we were to fork the build tools
and say, of one fork, that certain prereqs are assumable -- we still
should worry about bootstrapping.  It is Bad if you need a live
culture of particular software to bootstrap that same software.

One way to keep bootstrapping under control is to aim for tiny
languages that are less than fully general.  `make' is one example
(though, who knows, it may be formally turing complete).  I'd be
reluctant to leap to using Perl, Python, Ruby, or Scheme, for example,
unless the replacement for Makefiles did _not_ include arbitrary code
in any of those languages.

And, quite seriously: I think pedagogy has to be a consideration.
Implementing build tools offers novices an opportunity for a serious
hardcore tour of the system calls, file system issues, and more.  It
would be nice to hit an abstraction for build tools that doesn't
require a novice to "first step: implement python" if attempting a
fresh implementation.   It's funny, but unsurprising, how the
bootstrapping issue and the pedagogy issue mirror one another.

The `GNU make' maintainer seems to be actively making progressive
changes to GNU make.  If you have some complaint about make, working
with that project seems like an avenue worth exploring.

Timestamps vs. signatures?  Well, sure, timestamps are an unreliable
optimization that programmers have to understand thoroughly in order
to be able to use well.   Signatures _might_ be an improvement, or
they might just drag out edit/compile/debug cycles too long.  But
regardless, there are bigger fish to fry (auditing, automated
uninstall, dependency mgt, ...).

-t