Re: -MM, 2.95 vs 3.0

[Nathan Sidwell <nathan at codesourcery dot com>]

Ian Britten wrote:
I think you're using the wrong tool to solve the problem.
It might help to think about 'library' header files, as opposed to 'user'
or 'system' header files.

system header files are those which support the compilation environment, or
support the o/s (have intimate knowledge of the hardware).  These generally
contain some chicanery which, in user code, would elicit a warning.

library header files are those which support some random library of
utilities. system headers are a subclass of library headers

user header files are those which you are developing.

The behaviour that I understand that you want (and I can see the logic of),
is that once a dependancy reaches a library header file, the chain should
stop.

I'll answer in reverse order.

>   In-house, when we're developing our libraries/applications, the developers
>   obviously want to be dependent on our own work.  So, we #include our own
>   stuff with "", even from within our own header files.  However, once our
>   headers/libraries go to a customers site, we *become* the 3rd-party
>   software (to them).  We don't post-process our #includes, but our
>   customers  probably(?) don't want direct dependencies on our software (as
>   our code wouldn't change much as far as they are concerned)
>   Should we be changing all our "" to <> for them...?
No. the difference between <> and "" is *only* that "" first looks relative to
the directory containing the including file, before using the include search path.
Both <> and "" start at the begining of the include search path. You should
use "" if you want to locate the included file relative to the including file.
If the included file could be anywhere, use <>.

For instance, 
.../some/install/path/mylib.h
	#include "mylibconfig.h"
	#include "mylibsubsystem/subsystem.h"
.../some/install/path/mylibconfig.h
	whatever
.../some/install/path/mylibsubsystem/subsystem.h
	whatever

../user/code.cpp
	#include <mylibconfig.h>

Your library is guaranteed to #include the files you expect it to include, regardless
of whether the user has managed to put a different 'mylibconfig.h' or 'mylibsubsystem/subsystem.h' reachable by the include search path.

> Where we run into a problem is when working with 3rd-party (but non-system)
> header files (Stuff like GTK, PNG, ICU, etc).  By #including the 3rd party
> header files with <>, that acted like a stopping condition, meaning that we
> would have no dependencies on anything it subsequently included.  This was
> nice, as it could be controlled by the code *user*, and didn't matter
> whether the code *author* got the correct(?) #include syntax or not.
> If we _wanted_ to be dependent on them, we could simply #include them
> with "".
What you really want is a way of indicating that a header is a 'library'
header, rather than a 'user' header. The system header file distinction
is inadequate.

What about
	#pragma GCC library_header
? Its presence would cause the dependency graph to be terminated at this
header file. So that you could generate dependencies when developing the
library, you'd use something like
	#if !BUILDING_MYLIB_
	#pragma GCC library_header
	#endif
(Neil, do you think something like this would fly? It strikes me as a more
meaningful distinction for dependencies.)

> This becomes more obvious/useful when working with one set of code (and
> one set of dependencies), on multiple compiler/OSs, where the same 3rd
> party stuff may be installed in different directories.
why are you not regenerating the dependancy graph for different compilers
& OSs?

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org