[Top][All Lists]
[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.
- how to manage an unmanageable recursive make structure?, Robert P. J. Day, 2005/01/10
- Re: how to manage an unmanageable recursive make structure?, Noel Yap, 2005/01/10
- Re: how to manage an unmanageable recursive make structure?,
Robert P. J. Day <=
- Re: how to manage an unmanageable recursive make structure?, Noel Yap, 2005/01/10
- Re: how to manage an unmanageable recursive make structure?, Robert P. J. Day, 2005/01/10
- Re: how to manage an unmanageable recursive make structure?, Alessandro Vesely, 2005/01/11
- Re: how to manage an unmanageable recursive make structure?, Robert P. J. Day, 2005/01/11
- Re: how to manage an unmanageable recursive make structure?, Noel Yap, 2005/01/11