Re: converting to subdir-objects

[Bob Friesenhahn]

On Sun, 8 Mar 2015, Harlan Stenn wrote:
> > Due to the availability of Automake include files, hardly any text
> > need appear in a top-level Makefile.am, although the full content of
> > Makefile.in would appear at that location in the source package.
>
> I'll probably be doing that too, but at this point I'm looking at the
> "include" solution more for a conversion to non-recursive Makefiles,
> which I'm also not thrilled about because there are plenty of times I
> want to go to a specific directory and run "make" and have it DTRT.

> From your description, it seems that some target object files (the 
ones arrived at via ../) may be built by multiple Makefiles because 
these are deemed to be shared files.  This seems problematic.

When convenience libraries are used, usually just one Makefile is 
responsible for building that convenience library and recursion is 
used to enter the directory to build that library.  This assures 
consistent build options but it also dramatically slows the build. 
If the source files were fully enumerated (listed) by the Makefile for 
the using application, then there could be simultaneous requests to 
build the same object at once and the options provided during the 
build might not be consistent.  If there is just a single Makefile for 
the whole project then these issues disappear and the need (and 
hopefully desire!) for evil convenience libraries also should 
disappear.

If you want to emulate old style per-directory builds, why not put a 
tiny classic Makefile there which executes make on the master Makefile 
and requests only the target(s) which may be built in that directory? 
This will not eliminate other re-builds found necessary due to source 
file changes (only for those necessary for current targets), but would 
result in only the target(s) for that directory being built.  The 
incremental build time would still be reduced.

Turn convenience libraries into Makefile variables since Makefile 
variables are vastly more efficient than clunky convenience libraries.

This is what I tremendously enjoy seeing (since September, 2004):

Whole project with nothing to do (no "Making all in dir" messages) ...
% time make -s
make -s  0.46s user 0.03s system 88% cpu 0.562 total
% time make -s
make -s  0.44s user 0.01s system 98% cpu 0.462 total

Specific target with nothing to do (still assured to be correct) ...
% time make -s ./utilities/gm
make -s ./utilities/gm  0.22s user 0.02s system 98% cpu 0.241 total
% time make -s ./utilities/gm
make -s ./utilities/gm  0.22s user 0.02s system 98% cpu 0.240 total

And there is the benefit that almost everything (except for linking) 
can be built simultaneously, using all available CPU cores.

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/