> That's the key distinction. Assume that your dependency graph has
> no cycles when looked at file by file. If you then collapse the
> nodes for each file in a directory into one node for the directory,
> you artificially introduce circular dependencies.
In real projects collapsing the graph rarely introduces any circular
dependencies. Certainly, it hasn't with Subversion; when we've had
circular dependencies, they've been real live design problems with the
libraries, not artificial problems of the build system.
> Even if you don't have circular dependencies between the
> directories, you do have order dependencies. Someone has to
> manually sort the dependency graph between the directories instead
> of leaving it to make. (I'm always in favor of making the computer
> do the work so that I don't need to...)
In real projects (at least of moderate size), sorting the directories
is generally trivial. Also, one big Makefile puts you at greater risk
of the "relying on dependency order" problem (where you write "foo:
bar baz" and bar actually needs to be built before baz, but you don't
have a baz: bar dependency and you don't notice a problem until
someone does a make -j).
Greg Stein wrote:
> Yup. It is quite easy to build the one thing you're concerned
> with. We don't have a notion of "everything in this directory", but
> when you consider it: that is a bit bogus (the collection of targets
> in any given directory is rather arbitrary w.r.t the desire to build
> something specific).
In theory it might be bogus, but in reality directories usually have a
solid meaning, like "the foo library and its tests".
The arguments for a single Makefile are valid but not even close to
compelling for real projects, and so a single Makefile winds up being
merely bizarre and different for no good reason. Having to "(cd
../..; make libsvn_foo)" instead of just "make" isn't the end of the
world, but it will irritate people who are used to doing it the normal
Anyway, I will shut up now that my objection has been registered and
the arguments have been made.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Oct 21 14:36:30 2006