From the doc, the %{VAR} is in expression, ${VAR} is in the configuration.
But what is the difference between them actually, I saw some configuration file use %{VAR} in configuration too.
It depends of the context:
In regular configuration, ${VAR} can be an environment variable inherited by Apache process or, since Apache 2.4, defined by a Define directive.
But, in values of Rewrite* directives:
${MapName:LookupKey} (note the : to distinguish a variable to a RewriteMap): is intended to dynacially map a value to an other via RewriteMap (like lower case a substring)
%{VAR} designates a predefined variable (see the list under RewriteCond's documentation) used for and only by mod_rewrite.
EDIT : I should search first in Apache's documentation:
The values of variables defined with the Define of [new from 2.4] or shell environment variables can be used in configuration file lines using the syntax ${VAR}. If "VAR" is the name of a valid variable, the value of that variable is substituted into that spot in the configuration file line, and processing continues as if that text were found directly in the configuration file. Variables defined with Define take precedence over shell environment variables. If the "VAR" variable is not found, the characters ${VAR} are left unchanged, and a warning is logged. Variable names may not contain colon ":" characters, to avoid clashes with RewriteMap's syntax.
Only shell environment variables defined before the server is started can be used in expansions.
(source)
Related
When using CMAKE_PREFIX_PATH as an environnment variable, I have a weird behaviour, which I can't find in documentation.
I want to search the prefix path in two location, let's call them /path/to/prefix1 and /path/to/prefix2.
This doesn't work : export CMAKE_PREFIX_PATH="/path/to/prefix1;/path/to/prefix2"
This does work : export CMAKE_PREFIX_PATH="/path/to/prefix1:/path/to/prefix2"
Obviously in Unix PATH variable use : as a separator, but in CMake list separator is ;, like documented here. In the same link, its not written that environnment variables are an exception.
It also is explicitly written that CMAKE_PREFIX_PATH is a semicolon-separated list, which is confusing.
So what's going on here?
EDIT: It seems that when giving the argument from the command line, it does work only with ; and not :, which is the opposite as using an environnment variable : e.g. cmake .. -D CMAKE_PREFIX_PATH="/path/to/prefix1;/path/to/prefix2" works.
The normal variable and the environment variable are treated differently and are documented separately. CMake tends to treat environment variables the same way as the system treats the PATH variable. CMake normal variables are typically semicolon-separated (the most notable exceptions are the _FLAGS variables, which are space-separated for historical and backwards compatibility reasons).
For the environment variable CMAKE_PREFIX_PATH, the documentation says:
This variable may hold a single prefix or a list of prefixes separated by : on UNIX or ; on Windows (the same as the PATH environment variable convention on those platforms).
https://cmake.org/cmake/help/latest/envvar/CMAKE_PREFIX_PATH.html
Meanwhile, for the normal CMAKE_PREFIX_PATH variable, the documentation says:
Semicolon-separated list of directories specifying installation prefixes to be searched by the find_package(), find_program(), find_library(), find_file(), and find_path() commands.
https://cmake.org/cmake/help/latest/variable/CMAKE_PREFIX_PATH.html
which I can't find in documentation.
I found this simply by searching "CMAKE_PREFIX_PATH" in the documentation side-bar.
I would like to set up a cmake script with some options (flags and strings). For some of the options I would like to use environment variables as a default. Basically, I'm trying to emulate something like MY_OPTION ?= default in a Makefile. I tried the following:
project (Optiontest)
option(MY_OPTION
"Documentation"
$ENV{MY_OPTION}
FORCE)
message("value: ${MY_OPTION}")
I called this in the following way:
$ cmake -DMY_OPTION=ON .
value: ON
$ cmake -DMY_OPTION=OFF .
value: OFF
$ MY_OPTION=OFF cmake .
value: OFF
$ MY_OPTION=ON cmake .
value: OFF
My problem is that the last line should be ON as well.
For bonus karma: I would actually prefer three levels of preference. The value of -DMY_OPTION should be used if given. If not, the value of a set environment variable MY_OPTION should be used. If this is also not set, a constant should be used. I guess, I could use a bunch of nested if statements and somehow check if the variables are set, but I don't know how and I hope there is a better way.
FORCE is (as of CMake 3.0.2) not a valid parameter for option.
This is the primary source of problems. CMake will interpret the string FORCE as the desired initial value of the option in absence of an environment variable. The usual contrived rules for string-to-truth-value-conversion apply, resulting in the option being set to OFF by this call.
Second, you need to account for the fact that the environment variable is not set. Your current code misses to handle that case properly. $ENV{MY_OPTION} will evaluate to the empty string in that case. If you evaluate the set values in both the cache and the environment, you can enforce any behavior that you want.
In general, you should think about what you actually want here. Usually, FORCE setting a cached variable is a bad idea and I would not be surprised if you found your initial argument for doing this flawed after some careful reevaluation.
Maybe value of MY_OPTION cached in CMake cache? Do you try to clean cmake cache after third call MY_OPTION=OFF cmake .?
Consider the following:
SET(TEST_DIR, "test")
INSTALL(PROGRAMS scripts/foo.py DESTINATION ${TEST_DIR})
INSTALL(PROGRAMS scripts/foo.py DESTINATION #TEST_DIR#)
The first INSTALL command does not work. The second does. Why is that? What is the difference between those two? I have not found any reference to ## expansion except in the context of creation of configuration files. Everything else only uses ${} expansion.
UPDATE: OK, obvious bug in the above. My SET() command has an extraneous comma. Removing it, such that it looks like:
SET(TEST_DIR "test")
results in both ## and ${} expansions working. Still wondering (a) what is the meaning of ## as opposed to ${}, and why only the former worked with my incorrect SET() statement.
According to the documentation for the configure_file() command when configuring a file both the ${VAR} form and #VAR# form will be replaced VAR's value. Based on your experience above and some testing I did both forms are replaced when CMake evaluates your CMakeLists.txt, too. Since this is not documented I would recommend against using the #VAR# from in your CMakeLists.txt
Note that when using configure_file() you can restrict replacement to only the #VAR# form by using the #ONLY argument.
As far as I know, the #VAR# syntax is only used when replacing variables with the configure_file command.
Note that the configure_file command allows for an extra option #ONLY. Using it you can specify that only the #VAR#'s are replaced, but that the ${VAR}'s are kept.
As an example, this can be useful when generating e.g. a cmake-file which is later to be used with CMake again. E.g. when building your project, the #VAR# will be replaced when using configure_file. After you distributed your project and someone else uses the generated UseProject.cmake file, the ${VAR}$ entries will be replaced.
I have added a subdirectory in CMake by using add_subdirectory. How can I access a variable from the scope of that subdirectory without explicitly setting the variable by using set in combination with PARENT_SCOPE ?
set(BOX2D_BUILD_STATIC 1)
set(BOX2D_BUILD_EXAMPLES 0)
set(BOX2D_INSTALL_BY_DEFAULT 0)
add_subdirectory(Box2D_v2.2.1)
message(STATUS "Using Box2D version ${BOX2D_VERSION}")
# how to get ${BOX2D_VERSION} variable without modifying CMakeLists.txt in Box2D_v2.2.1?
Is this possible?
If the variable is a plain variable (as opposed to a cache variable), there is no way to access it from the parent scope.
Cache variables (those set with set(... CACHE ...)) can be accessed regardless of scope, as can global properties (set_property(GLOBAL ...)).
While #Angew's answer is correct, there aren't many things that are really impossible with CMake :-)
If you have a line like
set(BOX2D_VERSION 2.2.1)
in Box2D_v2.2.1/CMakeLists.txt, then you can retrieve the version in the parent scope by doing something like:
file(STRINGS Box2D_v2.2.1/CMakeLists.txt VersionSetter
REGEX "^[ ]*set\\(BOX2D_VERSION")
string(REGEX REPLACE "(^[ ]*set\\(BOX2D_VERSION[ ]*)([^\\)]*)\\)" "\\2"
BOX2D_VERSION ${VersionSetter})
This is a bit fragile; it doesn't accommodate for extra spaces in the set command for example, or cater for the value being set twice. You could cater for these possibilities too, but if you know the format of the set command and it's unlikely to change, then this is a reasonable workaround.
I use CPLUS_INCLUDE_PATH environment variable to compile .cpp files and it works fine to find .h files.
But it's not ok to compile ObjC or ObjC++.
Do you know the good one variable.
Thanks.
From the manual page:
CPATH
C_INCLUDE_PATH
CPLUS_INCLUDE_PATH
OBJC_INCLUDE_PATH
Each variable’s value is a list of directories separated by a
special character, much like PATH, in which to look for header
files. The special character, "PATH_SEPARATOR", is target‐
dependent and determined at GCC build time. For Microsoft Windows‐
based targets it is a semicolon, and for almost all other targets
it is a colon.
CPATH specifies a list of directories to be searched as if
specified with −I, but after any paths given with −I options on the
command line. This environment variable is used regardless of
which language is being preprocessed.
The remaining environment variables apply only when preprocessing
the particular language indicated. Each specifies a list of
directories to be searched as if specified with −isystem, but after
any paths given with −isystem options on the command line.
In all these variables, an empty element instructs the compiler to
search its current working directory. Empty elements can appear at
the beginning or end of a path. For instance, if the value of
CPATH is ":/special/include", that has the same effect as
−I. −I/special/include.