[Cmake] Problem seen in CMake 2.0.1 not seen in 1.8.3

[Brad King]

Karelitz, David B wrote:
>>Hi,
>>
>>I'm having a problem with CMake 2.0.1. The following line:
>>ADD_DEFINITIONS( -DFOO="${PROJECT_SOURCE_DIR}/Foo" )
>>used to compile using CMake 1.8.3. In Cmake 2.0.1 $(PROJECT_SOURCE_DIR)
>>either has a space at the beginning of the name or a space is added
>>somehow, so the compiler option is no longer correct. i.e. instead of
>>"-DFOO=path/to/foo" the result is "-DFOO= /path/to/foo". The result is
>>that the program no longer compiles.
>>
>>Is there some workaround for this, or a better way to have the same
>>functionality?

The CMake language did not originally intend for the syntax you are 
using to be valid, but a bug in the parser implementation allowed it to 
work.  In CMake 2.0 a new parser implementation was added that causes 
-DFOO= to be parsed as one argument and "${PROJECT_SOURCE_DIR}/Foo" to 
be parsed as a separate argument.  This causes the arguments to be added 
as separate definitions.

I've modified the new parser to allow this syntax for backward 
compatibility purposes.  The fix will be included in the 2.0.2 release.

For now, you can solve your problem by changing the line to look like this:

ADD_DEFINITIONS( -DFOO=\"${PROJECT_SOURCE_DIR}/Foo\" )

Note that the double-quotes are escaped.

If you are trying to configure your project's source tree into the 
executable, I suggest you instead configure a header file:

// mySourceDir.h.in
#define MY_SOURCE_DIR "@PROJECT_SOURCE_DIR@"

------------------

# CMakeLists.txt
CONFIGURE_FILE(${PROJECT_SOURCE_DIR}/mySourceDir.h.in
                ${PROJECT_BINARY_DIR}/mySourceDir.h @ONLY IMMEDIATE)

Then you can #include the header file to get the definition.  This 
approach is typically safer than using ADD_DEFINITIONS.

-Brad