how to properly define a make file that builds two distinct objects

[Robert P. J. Day]

  (no, it's not as lame-brained as it sounds, bear with me.)

  i'm currently in the process of redesigning someone else's
hierarchical make setup, which involves way too much duplicated
content in every makefile, so here's what i normally do.

  typically, a directory in a recursive make tree is responsible for
building a single object of some kind -- say, an executable, or a
shared library, or a loadable module, or what have you.  if that's the
case, my approach is to define a number of includable makefiles, one
for each kind of object to be built.

  for example, i might create a makefile called "sharedlib.mk" that
creates a shared library; all it needs is some well-defined variables
to be set to the appropriate values, then to include the "building"
makefile, as in:

Makefile
========

  TARGETLIB = fubar.so
  SRCS = src1.c src2.c snafu.c

  include sharedlib.mk

naturally, i'll define the rules in "sharedlib.mk" to need nothing
more than valid values in TARGETLIB and SRCS, and it will take it from
there.  that part's easy.

  obviously, i can do the same to build an executable, or a loadable
module, etc, etc.  but what if the "building" of that directory
should result in a multitude of final objects -- say, an executable, a
shared library *and* two loadable modules?

  if that's the case, i can't use the above approach since some of the
variable settings might trip over each other, and it's almost
certainly wrong to then finish the makefile with:

  ...
  include "sharedlib.mk"
  include "module.mk"
  include "executable.mk"


if i try that, i think it's safe to say that bad things will happen as
the combination of all those rules is going to clash badly?  so, what
to do?  i can see a couple strategies.

  1) further break the directory down into single-object
subdirectories, or

  2) create separate ".mk" files in the directory, which are invoked
from the Makefile and each of which is responsible for one of those
output types.

  are there other approaches that people use?  i'm just interested in
"best practices" here.  thanks.

rday
--

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================