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: Robert P. J. Day
Subject: Re: how to manage an unmanageable recursive make structure?
Date: Mon, 10 Jan 2005 08:09:25 -0500 (EST)

On Mon, 10 Jan 2005, Noel Yap wrote:

> 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.

  let me post one more article on this just to make it clear what i
was going to do with those variables.  (i'll use only include files as
an example -- the same logic will apply to augmenting "-L" for
searching for shared libs.)

  given my recursive make directory structure, it's my opinion that
*any* makefile anywhere in the structure should be able to include
header files from either of two locations without any help:

  1) standard system directories (you know, /usr/include, ...)
  2) from within their own current directory or below

so, WRT 2), it shouldn't be surprising to see a makefile containing
something like "-I. -I./include".  and if that's all that we needed,
there'd be no need for that INC_DIRS variable.

  however, if there's any need for searching for header files
*anywhere* else, it's the job of the higher-level makefiles to set
INC_DIRS and pass that down to augment the search path.  this will
include searching in a parent's "include/" directory.

  some of these makefiles actually contain "-I../include", as if it's
the most natural thing in the world to look in your parent directory's
include directory.  i would remove those references, and rewrite the
parent makefile to add that reference to INC_DIRS.

  like i said, i think every makefile should be able to search either
the system directories or its very own current directory for header
files or shared libs.  *any* other search path information should be
handed to it from above.

rday

p.s.  and regarding your distinction between include <> and include
"", my preference would be to use include <> everywhere, and
explicitly have to add "-I." to the search path.  is that what you
were saying?  it may seem a bit non-standard, but it does avoid
accidentally picking up a header file in the current directory if you
never planned on having any header files there.





reply via email to

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