help-make
[Top][All Lists]
Advanced

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

Re: how to manage an unmanageable recursive make structure?


From: Noel Yap
Subject: Re: how to manage an unmanageable recursive make structure?
Date: Mon, 10 Jan 2005 07:26:00 -0500
User-agent: Mozilla Thunderbird 0.5 (Windows/20040212)

I don't see anything blatantly wrong with your solution.

I would like to go over the (practical rather than theoretical) difference between #include 
"" and #include <>, though.

#include <> will use the include path to find the header file.  #include "" 
will first look within the directory of the includer before using the include path.

Because of this #include "" should be used when including files relative to the includer although it's extremely bad practice to start going into parent directories since it makes reorganizing extremely difficult as you've seen. Rather than #include "" with parent directories, #include <> should be used with proper include paths.

Oh, I almost forgot, if you stick to the above, having relative directories 
within the include path becomes unnecessary.  IME, having relative directories 
in the include path can cause problems and the above is a best practice for 
#include's.

HTH,
Noel

Robert P. J. Day wrote:

  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


_______________________________________________
Help-make mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/help-make




reply via email to

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