Re: how to manage an unmanageable recursive make structure?

[Noel Yap]

Robert P. J. Day wrote:

> On Mon, 10 Jan 2005, Noel Yap wrote:
>
>   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

1) may depend upon your environment.  There are times when one may want to 
switch standard header files (eg substitute RogueWave standard header files for 
the compiler-provided ones).  YMMV.

If you s/\*any\* makefile/\*any\* C or C++ file/ then I completely agree with the rest.  The 
latter should be done via #include "" rather than #include <>.  -I. should not 
be in the include path.

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

It's /my/ opinion that 2) should be done via #include "" rather than via the 
include path.

Let's say there are multiple files named aoeu.h.  Let's also say you don't have control over all the header file names (eg third party libraries, system headers, ...).  If a header file does #include <aoeu.h>, and it intends to include the one that's 
related to that header file (eg the one in the same directory), how can it guarantee the right aoeu.h is included?  Having -I. in the include path won't do this since the "." means the directory in which the compiler was invoked in.  Putting the aoeu.h's 
paths in the include paths will wind up including the wrong aoeu.h in at least some of the header files.

The only robust (eg makes no assumptions about include path) solution is to #include 
"aoeu.h".  Also, since it first checks the includer's directory, it's also much 
faster than traversing the include path.

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

I agree.  I would add that relative paths should be converted to absolute 
paths.  When generating dependencies files, one would want to guarantee 
absolute paths in them to make them usable from any makefile.

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

This is correct.

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

Right.

Noel