help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

how to manage an unmanageable recursive make structure?


From: Robert P. J. Day
Subject: how to manage an unmanageable recursive make structure?
Date: Mon, 10 Jan 2005 04:52:39 -0500 (EST)

  to make an ugly story as short as possible, i've inherited a
recursive make directory structure in which there are *numerous*
examples of C source file includes and shared library references that
reference locations, say, three levels up, one over, and two down.
you can actually see C languange include directives of the form

  #include "../../../foo/bar/fred.h"

and things like that.  or, in some cases, absolute pathnames as well.

  the obvious solution is, of course, to reorganize the entire
directory structure so that it's more modular, but that doesn't look
like an immediate option.  you all know the protests: "no, don't touch
anything.  it works right now, don't mess with it!"

  as a tacky, temporary fix, i'm going to at least insist that, at any
level in the entire structure, any makefile should be runnable with
nothing more than its current directory contents and what is passed to
it via options or the environment from its invoking parent makefile.

  to that end, i'm going to define two variables:

        INC_DIRS        # header file include directories
        LIB_DIRS        # shared lib directories for linking

that every makefile is responsible for modifying/augmenting before
calling its lower level recursive makefiles.

  then, as an example, the general form of a makefile will begin with
(in simplified form):

        INC_FLAGS := $(addprefix -I, $(INC_DIRS))
        LIB_DIR_FLAGS := $(addprefix -L, $(LIB_DIRS))

        demo.o: demo.c
                gcc -Wall -g -c demo.c -o demo.o ${INC_FLAGS}

        demo: demo.o
                gcc -g -o demo demo.o ${LIB_DIR_FLAGS} -l<libname>


that is, those two variables will be used to refer to either header
file directories or shared lib dirs *outside* the normal locations.

  thoughts on this approach?  it's the best i could come up with given
that i'm not allowed to move stuff around.  and even if i *could*
reorganize the structure, this approach is still useful for the
occasional case when you still need to include locations that are out
of the way.

  again, thoughts?  or am i making this too difficult and there's an
easier way to do it?  thanks muchly.

rday




reply via email to

[Prev in Thread] Current Thread [Next in Thread]