Thanks Brad for replying. Comments below.
On Wed, Jan 22, 2014 at 11:09 AM, Brad King <[email protected]> wrote: > On 01/22/2014 11:27 AM, Brian Davis wrote: > > > http://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/manual/cmake-language.7.rst;hb=1b395813#l393 > > > > This document does not state any persistence a variable should have > > when terms INTERNAL or FORCE are used. > > It does link to the set() command documentation > > http://www.cmake.org/cmake/help/v2.8.12/cmake.html#command:set > > which does explain INTERNAL and FORCE. (The reason I posted a > link to the version control viewer instead of published docs is > because that cmake-languages.7 manual has not yet been in a > release so it is not published anywhere persistent yet.) > > However, your problem has nothing to do with setting the cache > value, or FORCE, or INTERNAL. See below. > > On 01/17/2014 03:14 PM, Brian Davis wrote: > > 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") > > This is the fundamental problem. This is setting a normal variable > in the *directory scope* of the project. The document I linked > explains how variable value lookup occurs, and that directory scope > bindings are preferred before cache entries. Therefore this line > of code in the project *tells CMake to ignore the cache entry* so > it doesn't matter how you try to set it with ExternalProject_Add. > > ***This restriction is a bug in that project and not in CMake.*** > > 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. 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). 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. 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. 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. > > Then I think ok let's force it. Where I think my options are: > > > > 1) patch > > This would work but your arguments against it are valid. > Having "cmake -E patch" would be nice but it it non-trivial > to implement as discussed in > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48648 > > 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. > You could also write a .cmake script to edit the code using > file(READ), string(REPLACE), and file(WRITE) and run that script > as the ExternalProject patch step. > > 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. For those reading this and looking for an alternate to above. From ExternalProject_Add #--Custom targets------------- [STEP_TARGETS st1 st2 ...] # Generate custom targets for these steps where one of the st[N] targets you specify could also do the trick (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" > > The documentation is correct and this does set the cache entry, but > since *the project tells CMake to ignore the cache entry* it doesn't > matter how you set it. > > > 3) use -C to cache string force the variables in as specified > > http://cmake.org/Wiki/CMake_FAQ#Make_Override_Files > > Ditto #2. > > Man this was going to be my next try, but from what I am reading that wont work either. > > 4) Something I had not thought of. Recommendations welcome > > Apply the patch manually and create a new tarball to publish at > a URL you control and give that to ExternalProject_Add. Using > a URL you control also allows you to ensure that it persists > into the future as long as you need it. > Ouch. err less disk space in my git repo (though I have done this) if I ExternalProject_Add and patch.
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
