list #include path ?

[dave6502]

Struggling newbe here, some of my #includes work, some dont. Is it
possible to list the include path ? (in BASH),

I have looked at the environmental variables (loads of them) but
cannot find a reference.

Cheers

Dave

 

[Alf P. Steinbach]

* (e-mail address removed):

Struggling newbe here, some of my #includes work, some dont. Is it
possible to list the include path ? (in BASH),

I have looked at the environmental variables (loads of them) but
cannot find a reference.

As I understand it you want to specify the include path in the source code.

That's formally implementation specific, but most implementations (even
for Windows) support Unix-style forward slashes as path element
separators, so you can write

#include <someplace/wherever/theheader.h>
#include "someplaceelse/theotherheader.h"

The formal difference is that the "..." performs some extra searching
first, and if that doesn't find the header, does the same as <...>.

The in-practice difference is that the extra searching is in the
directory of the file containing the #include directive, i.e., "..."
will pick up a local file if there is one.

If instead you meant, how to find out the paths of the files actually
included, then that is implementation specific and generally off-topic
in clc++m. But e.g. g++ has the option "--print-search-dirs". I've
never used it, I just looked at the compilers short help listing, and
that's the general advice for implementation- and environment-specific
question (if that's what this was): read the manual, whatever you have.

Hth.,

- Alf

 

[James Kanze]

* (e-mail address removed):

As I understand it you want to specify the include path in the source code.

I'm not sure if that's what he wants. I think (but I'm not sure
either) that what he wants is to know where the compiler is
looking. Which is obviously implementation specific: g++ has an
option -print-search-dirs, and also an option -v which will show
the full paths (including those you specified by means of -I)
passed to the preprocessor, during a real compilation. (Note
that these paths are generally fixed during the generation of
g++, and may vary from one installation to the next.) VC++, as
far as I can tell, doesn't have anything "fixed", but depends on
$INCLUDE (or rather %INCLUDE%)---which again will vary depending
on where you install the compiler (and the system libraries,
which aren't bundled with the system or the compiler).

That's formally implementation specific, but most implementations (even
for Windows) support Unix-style forward slashes as path element
separators,

Just a nit, but Windows itself recognizes '/' as a directory
separator, at the lowest level. (Some utilities, however, will
not accept it in command line arguments, interpreting it as an
option specifier.)

so you can write

#include <someplace/wherever/theheader.h>
#include "someplaceelse/theotherheader.h"

The formal difference is that the "..." performs some extra searching
first, and if that doesn't find the header, does the same as <...>.

The in-practice difference is that the extra searching is in the
directory of the file containing the #include directive, i.e., "..."
will pick up a local file if there is one.

G++ (and probably others) also allows specifying paths in the
command line which are only searched for "..." includes.

If instead you meant, how to find out the paths of the files actually
included, then that is implementation specific and generally off-topic
in clc++m.

If he's concerned about where some symbol is actually coming
from, all of the compilers I know accept -E (or /E under
Windows), to output the preprocessor output to standard out.
This output normally contains #line directives with the full
path name; I've found this useful more than once to find out
where some strange symbol is coming from. (Or more often, to
discover that some header has unexpectedly defined a macro with
a name that conflicted with something I was trying to use.)

But e.g. g++ has the option "--print-search-dirs". I've
never used it, I just looked at the compilers short help listing, and
that's the general advice for implementation- and environment-specific
question (if that's what this was): read the manual, whatever you have.

The correct answer to all of this should be "read the manual".
In practice, however... most compiler documentation is pretty
poor.