Re: [CMake] Overriding CMAKE__FLAGS on a per target basis for Visual Studio project generation
Okay. I sort of thought that might be the case. I think I could work
around the whole problem if there were configuration-specific versions
of COMPILE_FLAGS... oh well.
Now I'm just working out a way to get this to compile two versions of
the library without having to list the source files in two different
places
Thanks for your help!
On Fri, Apr 20, 2012 at 3:31 PM, Fraser Hutchison
wrote:
> Hi Dan,
>
> I don't think it's possible to set compiler flags on a per-configuration,
> per-target basis without splitting your project.
>
> There was a very similar discussion recently [1],[2] which indicated a
> couple of options. However the first option can't be used on a
> per-configuration basis, which I imagine you'd need since you'll be wanting
> /MTd and /MDd for debug builds.
>
> So you're left with using add_subdirectory() along with a separate
> CMakeLists.txt for this subdirectory which defines the flags appropriate for
> its targets, and which can have entirely different flags to its parent.
>
> Cheers,
>
> Fraser.
>
> [1] http://www.cmake.org/pipermail/cmake/2012-April/049927.html
> [2] http://www.cmake.org/pipermail/cmake/2012-April/049938.html
>
>
>
>
> On 20/04/2012 08:31, Dan Peterson wrote:
>>
>> I love cmake, but I am still a bit of a novice, so perhaps there is a
>> better way to approach this problem. I am building a library using
>> cmake. On Windows I need to be able to build two versions: one that
>> links statically to the CRT (/MT) and one that links dynamically to
>> the CRT (/MD). I would like to avoid setting properties on
>> directories (not sure if it would work anyway) or doing anything that
>> requires me to split my project into two pieces.
>>
>> I know there is a general solution to the CRT linkage problem by
>> setting CMAKE__FLAGS globally (see
>>
>> http://stackoverflow.com/questions/1618927/cmake-microsoft-visual-studio-and-monolithic-runtimes).
>> It works great, but I cannot figure out a way to accomplish the same
>> thing on a per target basis.
>>
>> My CMakeLists.txt for this library is similar to the following:
>>
>>
>> INCLUDE_DIRECTORIES( "${PROJECT_SOURCE_DIR}" )
>>
>> SET( MYLIB_SRCS
>> foo.h
>> bar.h
>> baz.h
>> foo.cpp )
>>
>> IF( WIN32 )
>>
>> ADD_LIBRARY( MylibMD STATIC ${MYLIB_SRCS} )
>> ADD_LIBRARY( MylibMT STATIC ${MYLIB_SRCS} )
>>
>> # Statically link to Visual C++ CRT
>> FOREACH( Flag_var CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS_DEBUG
>> CMAKE_CXX_FLAGS_RELEASE CMAKE_CXX_FLAGS_MINSIZEREL
>> CMAKE_CXX_FLAGS_RELWITHDEBINFO )
>> IF( ${Flag_var} MATCHES "/MD" )
>> STRING( REGEX REPLACE "/MD" "/MT" "${Flag_var}MT"
>> "${${Flag_var}}" )
>> SET_TARGET_PROPERTIES( MylibMT PROPERTIES
>> "${Flag_var}" "${${Flag_var}MT}" )
>> # I also tried this
>> # SET_PROPERTY( TARGET MylibMT PROPERTY
>> "${Flag_var}" "${${Flag_var}MT}" )
>> ENDIF( ${Flag_var} MATCHES "/MD" )
>> ENDFOREACH( Flag_var )
>>
>> ELSE( WIN32 )
>>
>> ADD_LIBRARY( Mylib STATIC ${MYLIB_SRCS} )
>>
>> ENDIF( WIN32 )
>>
>>
>> I tried adding this in with COMPILE_FLAGS and other properties. I
>> also tried multiple things like the following in place of the for
>> loop:
>>
>>
>> SET_TARGET_PROPERTIES( MylibMT
>> PROPERTIES
>> STATIC_LIBRARY_FLAGS_DEBUG "/MTd"
>> STATIC_LIBRARY_FLAGS_RELEASE "/MT"
>> STATIC_LIBRARY_FLAGS_MINSIZEREL "/MT"
>> STATIC_LIBRARY_FLAGS_RELWITHDEBINFO "/MT" )
>>
>>
>> I found this thread on the mailing list:
>> http://www.cmake.org/pipermail/cmake/2010-August/039046.html, but
>> couldn't make any use of it, unless it would work to remove all CRT
>> linkage from the CMAKE__FLAGS and then add it back via
>> COMPILE_FLAGS or something else; but COMPILE_FLAGS doesn't seem to
>> have a per configuration variant.
>>
>> Please let me know if it is even possible to accomplish what I am
>> trying to do. Thanks.
>> --
>>
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Add --help-option command line option.
2012/4/20 David Cole : > 2012/4/20 Nicolas Desprès : >> 2012/4/20 David Cole : >>> 2012/4/20 Nicolas Desprès : 2012/4/20 Eric Noulard : > Le 20 avril 2012 13:40, Nicolas Desprès a > écrit : >> 2012/4/20 Eric Noulard : >>> Le 20 avril 2012 10:44, Nicolas Desprès a >>> écrit : Hi, I would like to have your opinion before to start to implement it. I would like to add the following options to the cmake command line interface: --help-option opt [file] = Print help for a given option and exit. --help-option-list [file] = List available options and exit. --help-options [file] = Print help for all options and exit. The goal is to have access to the project build options from the command line interface like you can see them in ccmake and cmake-gui. Advanced variable will be marked as such, of course. The output will be similar to --help-variable* options. I have noticed that most cmake based projects document their options in their README file whereas the documentation is already included in cmake when you call the option() and set() commands. I hope this feature will help to remove this duplication and people will just write in their README file a "see cmake --help-options for available build options". Comments? >>> >>> I think that Enabling/Designing some way to document user written CMake >>> scripts >>> is a very interesting goal. >>> >> >> Thanks. >> >>> I started doing something along that line using basic markup, which has >>> been >>> used to improve CPack documentation (--help-variable and >>> --help-command) in 2.8.8. >>> see: http://www.cmake.org/Bug/bug_relationship_graph.php?bug_id=10067 >> Thanks for the pointer. Indeed, it is nice piece of work. >>> >>> My approach does not need to actually "parse" CMake script but only to >>> catch comment line blocks. >>> I say that because the problem with options is that >>> you may need to parse **AND EVALUATE** some CMake script code >>> in order to know whether if the OPTION is active or not. >>> >>> See e.g. >>> cmake --help-module CMakeDependentOption >> >> Thanks for the pointer. I was not aware of this module. >> >>> >>> So how would grab the documentation from OPTION or >>> CMAKE_DEPENDENT_OPTION? >>> >>> 1a) Read out the provided CMake [file] and custom parse OPTION and >>> CMAKE_DEPENDENT_OPTION ? >>> (possibly disregarding the control flow like OPTION inside IF(WIN32), >>> IF(APPLE) etc...) ? >>> >>> 1b) Evaluate the CMakeLists.txt as ccmake and make-gui do? >>> >>> 2) Would you also handle "INCLUDE" and handle OPTION find in there as >>> well? >>> >>> I think that a full parse (as done by ccmake and/or cmake-gui) is not >>> easy at all. >>> I'd suggest to parse OPTION (and CMAKE_DEPENDENT_OPTION) found in any >>> CMakeLists.txt recursively, beginning with the one given on the command >>> line, >>> i.e. 1a) + recursion without 2). >>> >>> The main problem with this approach (be it recursive or not) is that >>> you may >>> list options which are platform dependent and/or conditionally >>> evaluated. >>> >>> Another way to go is to require an extra ##option markup (in any >>> script including CMakeLists.txt) >>> that could be placed anywhere but ideally just before the real >>> "OPTION/CMAKE_DEPENDENT_OPTION" statement. >>> That way you can parse it the way I did for CPack doc without the need >>> for any kind of CMake >>> script evaluation. >>> I know this duplicate the "comment" somehow, but it would give to the >>> developer a mean to >>> have more control concerning what is shown and what is not shown in >>> terms of documentation. >>> >>> Using this scheme we can imagine some "unified" way to get user doc >>> from user file (CMakeLists.txt or any *.cmake): >>> >>> --help-user-list --> list any user documented item from file >>> (variable, command/macro, option, property etc...) >>> --help-user --> dump all user doc whatever the category >>> >>> we can imagine some way to filter out the category we want >>> >>> --help-user-list option >>> --help-user option >>> --help-user variable >>> >>> etc... >>> >> >> First of all thanks for replying. Although, that's an interesting >> approach, I find it quite complex. Actually, I haven't dug into the >> source code yet but what I had in mind was to basically/naively do the >> same job that is done by ccmake and cmake-gui. I think (I haven't >> checked yet) the code is already factored in some way, so I could just
