[CMake] Forcing /MDd using externalproject_add

Brian Davis bitminer at gmail.com
Fri Jan 17 15:14:30 EST 2014


Lets say you download a swanky open source project off the web and hook it
into your project using he superbuild and externalproject_add.  You write
some code that uses said OSS project and you get the error in visual studio
2012.

Error    52    error LNK2038: mismatch detected for 'RuntimeLibrary': value
'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in some.obj
C:\someloc\someoss.lib(someother.obj)    your_app

In the past this did work and compile but no longer due to migration to VS
2012 library updates and and fresh maintenance builds from git of OSS repo
where before /MDd was used, but now /MTd is specified.  This is found by
grep'ing the source tree and finding the offending file and there the
following lines are found:

 # these settings never change even for C or C++
SET(CMAKE_C_FLAGS_DEBUG "/MTd /Z7 /Od")
...
...
the rest of the CMAKE compile variables.

That's rich.  The first line especially because git says otherwise in
released versions of said OSS software where that line has changed.  The
only constant is change.

Then I think ok let's force it.  Where I think my options are:

1) patch

2) pass the following into ExternalProject_Add and hope that the
documentation for cmake is correct (more on this later):
-DCMAKE_C_FLAGS_DEBUG:INTERNAL="/MDd /Z7 /Od"

3) use -C to cache string force the variables in as specified
http://cmake.org/Wiki/CMake_FAQ#Make_Override_Files

4) Something I had not thought of. Recommendations welcome


So 1 and 3 seem to go against my sensibilities (with my response to 2 being
- is this seriously this is the recommended approach), but 2 seems
reasonable except it does not appear :INTERNAL implies FORCE when using
ExternalProject_Add.  I am into oriental cuisine just like the next guy and
there are multiple ways to skin the cat, but it seems like 2 is least messy.

Also regarding 1, I too have used GNU Win32 Utils to use patch as CMake
does not have patch on windows as it relies on system so I have felt the
pain of the person who posted
http://comments.gmane.org/gmane.comp.programming.tools.cmake.user/48648 and
I too agree that some more good bits should be included in CMake.  Of
course once you go down that path then you might want svn, git, cvs, rcs,
and tetris (heck emacs has it why not cmake)

>From latest CMake documentation.

-D <var>:<type>=<value>

and

If <type> is INTERNAL, the cache variable is marked as internal, and will
not be shown to the user in tools like cmake-gui. This is intended for
values that should be persisted in the cache, but which users should not
normally change. INTERNAL implies FORCE.


Is this a bug?

I submitted to:
http://public.kitware.com/Bug/view.php?id=14705


Should/Does ExternalProject_Add allow a forced override using -D
<var>:<type>=<value> with type being INTERNAL?

If internal truly implies force and using externalproject_add I should be
able to use

-D VAR_NAME:INTERNAL="VALUE"

then why does it not override the internal setting of CMAKE_C_FLAGS_DEBUG
in the CMake file being processed by ExternalProject_Add?

-DCMAKE_C_FLAGS_DEBUG:INTERNAL="/MDd /Z7 /Od"

I now this because I verify the project files are getting the parameter
with grep:

 find someooss_proj-prefix/* -type f -name '*' -exec grep 'INTERNAL' {} + |
grep FLAGS | grep  C_FLAGS

and are promptly ignoring it due to the incessant linker error even after
blasting away the project (build directory) and allowing external project
add to pull new git repo and build from scratch.  For example see my
submittal to mantis above.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20140117/a839e3ec/attachment.html>


More information about the CMake mailing list