This is the mail archive of the
mailing list for the GCC project.
Re: -MM, 2.95 vs 3.0
- From: Nathan Sidwell <nathan at codesourcery dot com>
- To: Ian Britten <britten at caris dot com>
- Cc: gcc at gcc dot gnu dot org, Neil Booth <neil at daikokuya dot demon dot co dot uk>
- Date: Tue, 19 Feb 2002 21:53:45 +0000
- Subject: Re: -MM, 2.95 vs 3.0
- Organization: Codesourcery LLC
- References: <email@example.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
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 <>.
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
#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
#pragma GCC library_header
(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
Dr Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
'But that's a lie.' - 'Yes it is. What's your point?'
firstname.lastname@example.org : http://www.cs.bris.ac.uk/~nathan/ : email@example.com