<div dir="ltr">Thanks Brad for replying.  Comments below.<br><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 22, 2014 at 11:09 AM, Brad King <span dir="ltr"><<a href="mailto:brad.king@kitware.com" target="_blank">brad.king@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On 01/22/2014 11:27 AM, Brian Davis wrote:<br>
> <a href="http://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/manual/cmake-language.7.rst;hb=1b395813#l393" target="_blank">http://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/manual/cmake-language.7.rst;hb=1b395813#l393</a><br>

><br>
> This document does not state any persistence a variable should have<br>
> when terms INTERNAL or FORCE are used.<br>
<br>
</div>It does link to the set() command documentation<br>
<br>
 <a href="http://www.cmake.org/cmake/help/v2.8.12/cmake.html#command:set" target="_blank">http://www.cmake.org/cmake/help/v2.8.12/cmake.html#command:set</a><br>
<br>
which does explain INTERNAL and FORCE.  (The reason I posted a<br>
link to the version control viewer instead of published docs is<br>
because that cmake-languages.7 manual has not yet been in a<br>
release so it is not published anywhere persistent yet.)<br>
<br>
However, your problem has nothing to do with setting the cache<br>
value, or FORCE, or INTERNAL.  See below.<br>
<div class="im"><br>
On 01/17/2014 03:14 PM, Brian Davis wrote:<br>
> finding the offending file and there the following lines are found:<br>
><br>
>  # these settings never change even for C or C++<br>
> SET(CMAKE_C_FLAGS_DEBUG "/MTd /Z7 /Od")<br>
<br>
</div>This is the fundamental problem.  This is setting a normal variable<br>
in the *directory scope* of the project.  The document I linked<br>
explains how variable value lookup occurs, and that directory scope<br>
bindings are preferred before cache entries.  Therefore this line<br>
of code in the project *tells CMake to ignore the cache entry* so<br>
it doesn't matter how you try to set it with ExternalProject_Add.<br>
<br>
***This restriction is a bug in that project and not in CMake.***<br>
<div class="im"><br></div></blockquote><div>Apparently directory scope even overrides if INTERNAL which implies FORCE is used when specified from external interfaces such as command prompt and ExternalProject_Add.  If you are saying it should work this way then ... I guess it should work this way... though I really really which it did not.<br>
<br></div><div>But lets analyze the statement "is a bug in the project" for a moment.  Said project is DCMTK, but really does not matter.  Lets think of it as a Stand Alone Project (SAP).  Now SAP can be compiled on its own... or through the magic of ExternalProject_Add included in the build of a Super Build Project (SBP). <br>
<br>For what ever reason they (SAP) fliped to using /MTd when it was /MDd.  If compiled stand alone it is desired to work out of the box so the developers of SAP needed to specify CMAKE_C*_FLAGS* and friends to get it to compile right?.  They needed to specify something. Now some poor sap (me - not SAP) wants to build SAP in SBP along with some other SAP that uses /MDd and not /MTd... you seeing the problem here?  And thanks to the wonders on how CMake should/does work I can't seemingly reach in there and override (flip those bits) SAP from SBP.<br>
</div><div><br></div><div>Imagine that you are trying to get VTK, and DCMTK to compile.  VTK uses /MDd and DCMTK uses /MTd.  You try to get them to play nice in SBP along with boost .... and.... well I am in for a world-o-hurt.<br>
</div><div><br></div><div>So let's not refer to this as a "bug in project" (SAP), but rather a necessary setting that when used in a SBP with ExternalProject_Add appears to point to a use case which CMake simply appears not to handle all that well (at all).  Am I correct/incorrect on this assessment?  Unless you are saying that they should not have specified CMAKE_C*_FLAGS and friends in this way and should have use some unbeknownst to me and clearly them method.<br>
</div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
> Then I think ok let's force it.  Where I think my options are:<br>
><br>
> 1) patch<br>
<br>
</div>This would work but your arguments against it are valid.<br>
Having "cmake -E patch" would be nice but it it non-trivial<br>
to implement as discussed in<br>
<br>
 <a href="http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48648" target="_blank">http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48648</a><br>
<br></blockquote><div><br>Oh no I have already gone through this pain and I have it working as I posted earlier using gnuwin32 utils and my patch macro.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

You could also write a .cmake script to edit the code using<br>
file(READ), string(REPLACE), and file(WRITE) and run that script<br>
as the ExternalProject patch step.<br>
<div class="im"><br></div></blockquote><div>Man I don't even want to go there. As using git at patch is much easier having non-trivially implemented it. It is also more flexible.  Hack Hack Hack... git diff > patch_file.patch.<br>
<br>For those reading this and looking for an alternate to above.  From ExternalProject_Add<br>#--Custom targets-------------<br>    [STEP_TARGETS st1 st2 ...]  # Generate custom targets for these steps<br><br></div><div>
where one of the st[N] targets you specify could also do the trick (patch).<br><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
> 2) pass the following into ExternalProject_Add and hope that the<br>
> documentation for cmake is correct (more on this later):<br>
</div><div class="im">>  -DCMAKE_C_FLAGS_DEBUG:INTERNAL="/MDd /Z7 /Od"<br>
<br>
</div>The documentation is correct and this does set the cache entry, but<br>
since *the project tells CMake to ignore the cache entry* it doesn't<br>
matter how you set it.<br>
<div class="im"><br>
> 3) use -C to cache string force the variables in as specified<br>
> <a href="http://cmake.org/Wiki/CMake_FAQ#Make_Override_Files" target="_blank">http://cmake.org/Wiki/CMake_FAQ#Make_Override_Files</a><br>
<br>
</div>Ditto #2.<br>
<div class="im"><br></div></blockquote><div>Man this was going to be my next try, but from what I am reading that wont work either.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
> 4) Something I had not thought of. Recommendations welcome<br>
<br>
</div>Apply the patch manually and create a new tarball to publish at<br>
a URL you control and give that to ExternalProject_Add.  Using<br>
a URL you control also allows you to ensure that it persists<br>
into the future as long as you need it.<br></blockquote><div><br clear="all"></div></div>Ouch.   err less disk space in my git repo (though I have done this) if I ExternalProject_Add and patch.<br>
</div></div></div></div>