Re: Patch: RFC: fix for PR 46

[Alexandre Duret-Lutz]

>>> "Tom" == Tom Tromey <address@hidden> writes:

 Tom> This fixes PR automake/46.
 Tom> With this fix, you can add a directory and a top-level `make' will
 Tom> correctly automake and config.status the new directory.

 Tom> The drawbacks:

 Tom> * You must run `make' from the top build directory only; the feature
 Tom> won't work (but won't hurt) if you run make in a subdir

Maybe I'm mistaken, but It seems worse than this: this feature
seems to work only if the new directory is a child of the top
directory.  The top-level rebuild rules are not triggered if the
directory is added deeper in the hierarchy, because the
top-level Makefile.am will not be modified.

 Tom> * At the top level it always re-runs automake and config.status, which
 Tom> could be slow, especially for a large project

 Tom> In fact, the speed, especially of running automake, for a large
 Tom> project is largely what is stopping me from simply checking this in.
 Tom> Our test suite is deceptively simple here.  I suspect that running
 Tom> automake on something like gstreamer will give a very different
 Tom> feeling.

Yep, ISTR messages from people using _hundreds_ of Makefiles.

 Tom> If you read the PR, you'll see another idea from Alexandre Oliva,
 Tom> namely to make the recursive rules depend on each subdir Makefile.
 Tom> This is an attractive idea, but I think it has a major drawback.
 Tom> Suppose you want to remove a directory: you remove it from SUBDIRS,
 Tom> AC_OUTPUT, and the filesystem.  Then a simple `make' will fail,
 Tom> because the old Makefile won't find the now-removed Makefile.

Another problem is that the subdir Makefile is not necessarily
called `Makefile'.

[...]

-- 
Alexandre Duret-Lutz