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