[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
a couple questions about general makefile design principles
From: |
Robert P. J. Day |
Subject: |
a couple questions about general makefile design principles |
Date: |
Mon, 14 Jun 2004 21:13:20 -0400 (EDT) |
i'm looking at the makefile structure(s) of an existing project, and i'm
interested in others' opinions of some design/layout decisions, as i'm not
sure if those decisions are the standard make approach, or are in some
ways overkill and could be done in a different way.
first, there's a top-level included makefile, call it "main.mk", that
pretty much *every* make file at every level is expected to include. i
don't have a problem with that -- there are some useful macro defines,
such as what i suspect is a fairly common one:
define DO-SUBDIRS
@for d in ${SUBDIRS} ; do \
${MAKE} -C $$d $@ ; \
done
endef
that i have no problem with. but i'm curious about another part of
main.mk.
at the top, there are a number of variable definitions, call them
SHARED, LIBRARY, EXECUTABLE and so on -- types of objects that can be
built -- all of which are set to the name of another .mk file in that same
makefile include directory. each of those files contain rules specific
for how to create an object of just that type.
at this point, in any given makefile in the entire SW structure, that
makefile will include "main.mk", but will then, depending on what kind of
object is being created by this sub-makefile, will include the appropriate
makefile containing the appropriate rules for how to create it:
NAMEOFTHING = fred
include main.mk
include ${LIBRARY}
the above would represent a makefile in a directory where "fred" is to
be used as the name to, somehow, create a library, based on the rules
defined in that included makefile. if one had, instead, included:
include ${EXECUTABLE}
then the rules would have defined how to create an executable named "fred"
from whatever the contents of this directory was. and so on and so on,
one included makefile for each distinct type of object you might want to
create.
on the one hand, i can see how this kind of structure is incredibly
efficient, which is apparently why it was originally designed this way.
on the other hand, it strikes me that there are a number of drawbacks.
first, if you happen to take a look at any makefile in the entire
structure, it's pretty hard to understand what's going on. i mean, the
makefile is *so* terse, it tells you almost nothing.
second, it seems kind of inflexible -- if you want to build a library,
you use precisely the rules in the included makefile for building
libraries, and nothing else. in short, you better want to build a library
*exactly* the way the original designer had in mind.
anyway, i don't want to flog this any more than i have. i'm curious
about others' thoughts on this kind of structure -- what little i've
explained of it.
more questions coming soon.
rday
- a couple questions about general makefile design principles,
Robert P. J. Day <=