Re: The smart way to use make in a directory tree

[Josh Bialkowski]

On 07/17/2010 01:26 AM, David Boyce wrote:
> There may be a clever trick I don't know, but as far as I can tell
> there's a catch-22 here because you'd need to have some kind of
> makefile to set up VPATH first, which entails having a stub makefile
> in each dir, and once you've gotten to that point there are better
> options as discussed.

Got it.

> Advanced topic: one of the interesting things about make is that
> variable names can contain just about any character. This means, among
> other things, that paths can be part of variable names. So at large
> enough scale it may make sense to uniqify names using the dir name in
> an automated fashion. I.e. instead of $(lib1_objects) you'd use
> $($(thisdir)_objs) where thisdir can be determined from MAKEFILE_LIST
> as shown. I've done this; it scales well, at some cost to readability.

I like that idea. I will try it.


> Which puts me in mind of another advanced topic: a side effect of
> using fully-qualified pathnames is that the Makefile should be
> completely insensitive to the cwd. This can be easily tested; cd to
> some random place like /tmp and try "make -f
> /path/to/master/Makefile". It should work exactly the same.
>
> > > And then your build clauses would look mor or less like
> > >
> > > $(PROJECT_ROOT)foo.o: $(PROJECT_ROOT)foo.c:
> > >        $(CC) -c -o $@ $<

That is very handy!


> Although it's an orthogonal topic, it's a good idea to use implicit
> rules as much as possible. Especially in this model as it saves typing
> long pathnames and makes Makefiles more robust in the event of
> refactoring/renaming.

I already use implicit rules as much as possible. As mentioned, my 
previous attempt suffered because of this fact! I will keep using 
implicit rules then.

> - Take 2 minutes right away to read http://mad-scientist.net/make/rules.html.

I have that one in my bookmarks :).

> - When you have something working, read
> http://mad-scientist.net/make/autodep.html for dependency generation
> ideas.

And this one. This was the article that lead me to the fact that there 
is *a lot* more to make than first meets the eye.

> - And if you support or ever might support multiple target
> architectures: http://mad-scientist.net/make/multi-arch.html

Thanks, this one is nice too.

> - You might also want to look into GMSL
> (http://gmsl.sourceforge.net/). I've never used it myself but there's
> a lot of clever stuff there, freely available.

I'll look at it.


Thanks again for the help.