GNU make: recursive make vs single makefile - Linux

This is a discussion on GNU make: recursive make vs single makefile - Linux ; Hi * I just gain an experience in work with make. I encounter some interesting article in the net - http://www.canb.auug.org.au/~millerp...cons-harm.html - about *nix tradition of using make in a recursive manner and disadvantages of this way. The essence of ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: GNU make: recursive make vs single makefile

  1. GNU make: recursive make vs single makefile

    Hi *

    I just gain an experience in work with make. I encounter some
    interesting article in the net -
    http://www.canb.auug.org.au/~millerp...cons-harm.html -
    about *nix tradition of using make in a recursive manner and
    disadvantages of this way. The essence of the article, that when using
    recursive make, one have to use some workarounds to build project that
    leads to such problems as "build too little" or "build too much". This
    happens because of incomplete dependency graph of project. So the
    author of the article suggests to use a single makefile for a whole
    project. 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. What method is more
    reliable and easier maintainable applied to real world projects. And
    what about autotools and problems of recursive make? Does automake
    solve this problems?

    Thanks in advance.


  2. Re: GNU make: recursive make vs single makefile

    On 11 Dec 2006 11:13:21 -0800, Dmitry Chumack wrote:

    > http://www.canb.auug.org.au/~millerp...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/

+ Reply to Thread