Actually there is a way. But you should be careful to track in what scope particular flags are defined.<br><br>If you don't put a lot of stuff into directory scopes you can modify CMAKE_<LANG>_FLAGS and etc before calling to add_library/add_executable call. You can even completely replace them. As I understand calling set() command takes preference over cached variable and its value is restored when CMake leaves directory (if I'm right).<br>
<br>For example, we have a "treat warnings as errors" policy for 100+ projects, so we have /WX option in CMAKE_CXX_FLAGS. But for some legacy projects which we don't want to touch we use:<br># Don't treat warnings as errors.<br>
string(REPLACE "/WX" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})<br><br>As I said, you should be aware of the place where particular flag comes from. If you use directory-scope or source-file scope (or whatever) properties, you should modify them instead.<br>
<br><div class="gmail_quote">On Wed, Mar 30, 2011 at 10:00 PM, Whitcomb, Mr. Tim <span dir="ltr"><<a href="mailto:Tim.Whitcomb@nrlmry.navy.mil">Tim.Whitcomb@nrlmry.navy.mil</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Shortening to reduce wall-of-text:<br>
<br>
I have a Fortran project with a top-level CMakeLists.txt file with 47 add_subdirectory calls. Three of the subdirectories require a different set of preprocessor definitions and compiler flags than the other 47. I can add the preprocessor definitions, but am having trouble with the compiler flags. I need to have a completely different set in those subdirectories, so COMPILE_FLAGS target property won't work as it augments what's already there.<br>
<br>
How can I replace (not extend) the compiler flags for these few subdirectories?<br>
<font color="#888888"><br>
Tim<br>
</font><div><div></div><div class="h5"><br>
> -----Original Message-----<br>
> From: <a href="mailto:cmake-bounces@cmake.org">cmake-bounces@cmake.org</a><br>
> [mailto:<a href="mailto:cmake-bounces@cmake.org">cmake-bounces@cmake.org</a>] On Behalf Of Whitcomb, Mr. Tim<br>
> Sent: Friday, March 25, 2011 3:18 PM<br>
> To: '<a href="mailto:cmake@cmake.org">cmake@cmake.org</a>'<br>
> Subject: [CMake] Replacing compiler flags for certain project<br>
> subdirectories<br>
><br>
> I'm in the process of adding Cmake-build capability to a<br>
> Fortran project that currently follows a traditional<br>
> recursive-make build structure. I've converted all the<br>
> makefiles to CMakeLists.txt files and can now produce all the<br>
> target libraries and executables with their dependencies<br>
> correctly recognized. These dependencies have made a huge<br>
> difference in allowing us to perform parallel builds and have<br>
> the project ready to go *much* faster than before. I have a<br>
> top-level CMakeLists.txt file that contains a few library<br>
> searches (e.g. LAPACK, BLAS) and then an add_subdirectory<br>
> call for each subdirectory in the project. Each subdirectory<br>
> corresponds to a library and/or an executable.<br>
><br>
> Now that the listing files contain all the sources files they<br>
> need, my current task is to go through and set the proper<br>
> compiler/preprocessor flags to match the original makefiles.<br>
> We have several directories in our source tree that are<br>
> auxiliary libraries that we store in our Subversion<br>
> repository and build as part of our regular build process.<br>
> The libraries that are built in these directories are<br>
> compiled with different compiler flags and different<br>
> preprocessor definitions than the rest of the project. I've<br>
> been able to handle the preprocessor definitions by using<br>
> add_definitions in the CMakeLists.txt files in the<br>
> lower-level directories. I see based on reading through some<br>
> past threads (including the recent "Different CMAKE_CXX_FLAGS<br>
> for different executables") on this list and on some<br>
> StackOverflow questions that the COMPILE_FLAGS target<br>
> property is very close to what I need (and actually *was*<br>
> what I needed in several cases) but only appends flags to<br>
> those currently in use. What I need is to be able to define<br>
> a new set of compile flags (i.e. "forget everything you were<br>
> using before and use THIS set in this directory").<br>
><br>
> I've started going through the documentation for Building<br>
> External Projects[*] but the first line states that "[a]n<br>
> "external project" is one that you can get the source code<br>
> for, but does not readily build with a simple<br>
> ADD_SUBDIRECTORY call in your CMakeLists.txt file." This<br>
> feels like it's designed to solve a slightly different<br>
> problem than what I'm trying to do - I have an<br>
> add_subdirectory call in my CMakeLists.txt file - is the<br>
> proper fix for this issue to make the pieces that require<br>
> different flags external projects? Will making some of these<br>
> libraries external projects mess with the dependency calculation?<br>
><br>
> I'm just getting started and trying to wrap my head around<br>
> the options available. What is the standard way of dealing<br>
> with this issue? Is there anything I'm missing? Thank you<br>
> for your assistance!<br>
><br>
> Tim<br>
> [w]<br>
><br>
> [*]<br>
> <a href="http://www.kitware.com/products/html/BuildingExternalProjectsW" target="_blank">http://www.kitware.com/products/html/BuildingExternalProjectsW</a><br>
> ithCMake2.8.html<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br>