Re: how well does multi-arch build handle recursive building?

[Greg Chicares]

On 2006-5-12 11:07 UTC, Robert P. J. Day wrote:
> On Fri, 12 May 2006, Greg Chicares wrote:
> 
>>On 2006-5-11 18:23 UTC, Robert P. J. Day wrote:
>>
>>>  at the moment, i'm using paul's multi-architecture build described
>>>here:
>>>
>>>http://make.paulandlesley.org/multi-arch.html
>>>
>>>successfully for simple builds for which all of the source files
>>>are in a single directory.  (i'm not actually doing
>>>multi-architecture builds, i'm just using that technique to build
>>>the results in a remote directory.  same difference, obviously.)
>>
>>I use that technique in day-to-day production, for multiple
>>compilers, placing object and other binary files in compiler-
>>specific directories. Source files are scattered here and there, but
>>vpath means I don't need to worry about that.
>>
>>>so how well does that technique extend to recursive builds?
>>
>>It applies a single makefile recursively over directories.

Sorry, I should have said it invokes make recursively in a single
remote directory, and you can call it repeatedly to do so across
multiple directories for different architectures, or different
compilers, or different sets of compiler flags, etc.

> but *how*?  i understand well enough how the multi-arch approach works
> with all of the source files in a single remote directory that can be
> referenced via vpath.  (in fact, it's just as easy to see how that can
> work if the sources are scattered across *several* directories, as
> long as the objects are being constructed in a single build
> directory.)

Yes, exactly.

> but how does the multi-arch approach work if one tries to extend it to
> a recursive make structure?  you know -- the kind where part of the
> top-level makefile defines a number of SUBDIRS and reinvokes make with
> "make -C" for each of those SUBDIRS?

I've done this sort of thing:

.phony nightly_build
        -$(MAKE) all test CC=gcc
        -$(MAKE) all test CC=another_compiler
        ...

but I think you're doing something quite different. Where I'm
building my main program and its unit tests all in the same
directory, maybe you'd rather use separate directories. One
common way to do that is to have a separate directory for
unit-test source, and a separate makefile there that builds
only the tests. Maybe there's a 'configure' script that
writes a makefile in each source subdirectory, and one top-
level makefile to invoke them all.

If that's more like what you want to do, then I guess the
"multiple targets" technique might be an alternative way to
go about it, by defining $(EXTRATARGETS). The paper talks
about a source-code generator whose output is then built for
various architectures, but that's just one example.

Are there dependencies among your SUBDIRS? For instance, is
there one for the main program, and another for tests that
exercise it, or another for an optional plugin? Try mapping
your set of dependencies to the _common versus $(OBJDIR)
dichotomy in the paper.

> if you're trying to emulate the original recursive build, that would
> seem to mean that, for each sub-directory you move into, you need to
> redefine vpath to the corresponding sub-directory for the sources, no?

When source files are segregated into multiple directories,
sure, you'd need vpath to point to the appropriate place
for each target you're building. But then what advantage
do you seek from the "multi-arch" technique? Is it that
you currently create object files in each source directory,
and want instead to create them in a similar hierarchy
under a separate object directory? Or that you want to
extend your existing makefiles to handle, say, multiple
compilers? I don't think I understand what your goal is.

> do you have an actual example of the makefiles you're using to show
> how you're doing this recursive build?

I don't think I've ever done anything like what you've got
in mind.