Re: converting to subdir-objects

[Harlan Stenn]

Bob Friesenhahn writes:
> 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.

The usual case is one where I'm building a single library from sources
in multiple places.

There are more rare cases where I'll be using a single file for multiple
builds, and each will likely have some different -D flags passed in.

Not sure about this last one.  I know there are some files where I
created a small .c file that sets up the needed options using #define's
and I don't think I've had to mess with any of these for maybe 10 years'
time, so my recollection is fuzzy.  There are other cases where I am
building different .o files from the same .c file with differend -D
options, but those are all in the same subdir.

> 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.

I'm happy to look at that, and each of these Makefiles will need to be
generated by configure (config.status) because they need to be in the
build tree.  I figure that's a project to look at once I get
subdir-objects going.

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

I'm happy to look at that, and it means I'd want a single place to
define these Makefile variables and then I'd have to update all the
places they're used.

If with subdir objects this means a single copy of these files will be
built and shared that seems great.

I'm not seeing value in converting to Makefile variables at this point.

The current convenience libraries take a bit longer.  But I think we
only have one of them.

If converting to subdir objects doesn't make things much slower and it
avoids warnings, that's enough for me.

If a way can be found to get a non-recursive solution implemented as
well where we still have the "build" options we want, so much the better.

> 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.

That is great, especially if this approach is no slower for builds folks
have to do on single-core slow boxes, too.

H