您可以在C / C ++ include指令中使用环境变量吗？

Question

Say I have a folder layout as such:

.
+-- Project
    +-- src
        +-- foo.h
        +-- foo.cpp
    +-- test
        +-- test_foo.c

And test_foo.c looks as such:

#include "../src/foo.h"
#include <stdio.h>
#include <assert.h>

int main() {
    assert(foo() == true);
    printf("Test complete");
    return 0;
}

Is there a way to replace the line #include "../src/foo.h" with a variable that points to the source directory? For instance, say in my environment I have a have a variable:

PROJECT_SRC="./Project/src/"

And then I could have the include directive as such:

#include "PROJECT_SRC/foo.h"

This would be nice as I could then have a bash script that exports all the paths I need for a certain project. Also, if the file is included in different test and build files I would have to set up the relative path for each (although not much work) which would be less robust than one absolute path.

An alternative might be a tool like CMake that can do this. Or is this considered bad practice?

Answer 1

Weeelll...it is possible, sort of, but it's not pretty, and it has some pitfalls. It is usually better to add the include path in the build system, such as (assuming plain make ):

# C PreProcessor flags. This variable is used by make's implicit rules for 
# everything preprocessor-related.
CPPFLAGS += -I$(PROJECT_PATH)

and #include the headers without the path in the source file. This will make make call the compiler with -Iyour/project/path , which will make the compiler look for headers in your/project/path . That is to say, in the Makefile you can have

PROJECT_PATH = foo/bar
CPPFLAGS = -I$(PROJECT_PATH)

and in the sources

#include "foobar.h"

to have the effect of #include "foo/bar/foobar.h" .

...also, did I see you try to #include source files instead of headers? Do not go down that road; down that road madness lies. Compile the source files separately and link them together the usual way unless you have a really good reason to do otherwise.

So, I don 't see a reason why you would want to reference the project path directly in #include directives in the code; the only change on the build system side is only that you have to pass -DPROJECT_PATH=foo/bar/ instead of -IPROJECT_PATH=foo/bar/ and that the construct is more brittle than the mechanisms that are actually designed for this sort of stuff. But if you really want to do it, then here is how:

The first problem you run into is that

#include "foo/bar/" "baz.h" // no dice.

is ill-formed, so the easy way is out. We have to try preprocessor magic, and it works like this:

#define HEADER_STRING(s) #s
#define HEADER_I(path, name) HEADER_STRING(path ## name)
#define HEADER(path, name) HEADER_I(path, name)

//                                v-- important: no spaces allowed here!
#include HEADER(PROJECT_PATH,foobar.h)

Perhaps start from the bottom up:

#define HEADER_STRING(s) #s

makes a string from its argument. That is to say, HEADER_STRING(foo/bar/baz.h) expands to "foo/bar/baz.h" . Notably, macro parameters are not expanded, so HEADER_STRING(PROJECT_PATH) will expand to "PROJECT_PATH" even if a macro PROJECT_PATH is defined. This is one of the most common problems you run into when you try to do anything complicated with the preprocessor, and the solution is to add another layer in which the parameters can be expanded:

#define HEADER_STRING_I(s) #s
#define HEADER_STRING(s) HEADER_STRING_I(s)

...we do not need this for HEADER_STRING , but it is used in HEADER , so keep the trick in mind. I'm afraid the precise preprocessor substitution rules are somewhat arcane, and explaining them in detail goes beyond the scope of a SO answer. In a nutshell, macros are expanded in layers, and when macros don't get expanded, the trick is usually to give them a place to expand, ie, to add another layer.

HEADER_I then,

#define HEADER_I(path, name) HEADER_STRING(path ## name)

tapes its arguments together and passes them to HEADER_STRING . HEADER_I(foo,bar) expands to HEADER_STRING(foobar) . Because of the problem I mentioned above, HEADER_I(PROJECT_PATH,foobar.h) expands to HEADER_STRING(PROJECT_PATHfoobar.h) , which in turn expands to "PROJECT_PATHfoobar.h" , so we need another layer for the expansion of PROJECT_PATH :

#define HEADER(path, name) HEADER_I(path, name)

This just adds the place for the path and name parameters to be expanded. Finally, with PROJECT_PATH #define d to foo/bar/ , HEADER(PROJECT_PATH,foobar.h) expands to "foo/bar/foobar.h" , and then we can say

#include HEADER(PROJECT_PATH,foobar.h)

to #include "foo/bar/foobar.h" . PROJECT_PATH can then be set in the makefile and passed with -DPROJECT_PATH=$(some_make_variable) .

The last pitfall is that you must take care to not let any spaces slip between the tokens.

#include HEADER(PROJECT_PATH,foobar.h)

ultimately expands to "foo/bar/ foobar.h" (note the space), which does not work.