Re: GNU make: recursive make vs single makefile
- From: Bob Hauck <postmaster@xxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 13 Dec 2006 21:37:12 -0500
On 11 Dec 2006 11:13:21 -0800, Dmitry Chumack <saint.d.a@xxxxxxxxx> wrote:
http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html
I'm interested in are there anybody who is experienced in such a
technics of using single makefile and who knows in practice about
advantages and disadvantages of this two methods.
I have built a make system for a smallish project based more or less on
the ideas in that article. The project has six source subdirectories
and about 14,000 lines of C (not including headers). It creates about a
dozen executables and three static libraries. It builds natively for
i386 Linux and also cross compiles to PowerPC Linux using ELDK and on
Solaris 10 using the GNU toolchain.
As suggested, I split the makefiles up into sub-makes that get included
by the main makefile. I also made a set of macros so you could add new
targets to a sub-make using some simple syntax, for example:
TGT := orient
SRC := orient.c \
orient_nav.c \
orient_proc.c \
orient_sim.c \
orient_xbow.c
include $(scriptdir)/module_add.mk
These macros were probably the hardest part, but they save a lot of
duplication and make it almost trivial to add a new build target or
remove an unneeded one.
The method has some advantages:
1. If you change a function way over there in a library, only the
changed files (and dependencies in the case of headers) get rebuilt.
The programs that depend on the library just get re-linked. This works
reliably.
2. No worries about including header files across subtrees. The
dependencies are handled automatically.
3. You learn a lot about make syntax and features getting it working
the first time.
4. The sub-makefiles are pretty simple and it is easy for developers
who are not familiar with make to work with them.
5. Builds work correctly no matter where in the tree you are when you
invoke make, no matter what has been changed.
6. The ideas about automated dependency handling are very useful and
make the build a lot more robust against changes to buried dependencies.
It has been a while since I had to do "make clean" just to get a build
to work.
7. Despite all of the macros & stuff, I actually know what my makefile
is doing and can troubleshoot it. Autotools makefiles seem very obscure
to me, but I'm also not very experienced with them.
Disadvantages include:
1. The sub-makefiles are included rather than run by themselves. This
can lead to odd behavior when you define some variable and some other
sub-make defines the same variable. You quickly learn to use a prefix
or suffix scheme so variables are unique.
2. You don't get all the nifty feature-detection and cross-compile
macros that autotools gives you. You get to do that yourself.
3. You learn more than you wanted to know about make syntax and
features getting it to work the first time. There are no automated
tools as there are for automake.
4. Getting feature #5 above working involved a lot of tricky macros and
some GNU extensions.
All in all I'm pretty happy with the way the system turned out. There
are two other developers working with it, we have about four branches of
the project going right now for different hardware platforms, and so far
nobody is yelling about builds not working.
--
-| Bob Hauck
-| Hooray for San Fancisco values!
-| http://www.haucks.org/
.
- References:
- GNU make: recursive make vs single makefile
- From: Dmitry Chumack
- GNU make: recursive make vs single makefile
- Prev by Date: Re: doubts about disk scheduling
- Next by Date: Re: Makefile
- Previous by thread: GNU make: recursive make vs single makefile
- Next by thread: newbie delay/sleep question
- Index(es):
Relevant Pages
|
