[CMake] CMake command line arguments

Gabriel Petrovay gabipetrovay at gmail.com
Mon Mar 7 06:37:35 EST 2011


Thanks for the tips, Michael.

We will do so, using project specific BUILD_TYPE and INSTALL_PREFIX.


Gabriel

On Mon, Mar 7, 2011 at 12:20 PM, Michael Hertling <mhertling at online.de> wrote:
> On 03/07/2011 11:33 AM, Michael Hertling wrote:
>> On 03/06/2011 12:12 PM, Gabriel Petrovay wrote:
>>> Hi,
>>>
>>> Is there a way to read the arguments that were passed to CMake from
>>> inside a CMakeLists.txt file?
>>>
>>> There is a problem that some generators (like "NMake Makefiles") set a
>>> default value for certain variables (like CMAKE_BUILD_TYPE=Debug,
>>> CMAKE_INSTALL_PREFIX=C:\Program Files\${CMAKE_PROJECT_NAME})
>>>
>>> From inside CMake one can not set up a different default value if the
>>> user does not specify it with a -D option. This is because
>>> IF(CMAKE_BUILD_TYPE) will always be true because of the default set by
>>> the generator ("NMake Makefiles").
>>>
>>> There was this guy having the same problem:
>>> http://www.mail-archive.com/cmake@cmake.org/msg09640.html
>>>
>>> Any solution how one can solve this? Reading the arguments passed to
>>> CMake would be one, but I find no documentation/example/google_result
>>> for this.
>>>
>>>
>>> Thanks!
>>
>> Scanning the command line for user-supplied settings wouldn't be
>> reliable because your project might also be configured via a GUI.
>>
>> Furthermore, even an empty CMAKE_BUILD_TYPE variable may denote a
>> valid build type, so there's no robust criterion to decide when to
>> set a default value by examining this variable alone. Instead, you
>> might use another variable, say ${PROJECT_NAME}_BUILD_TYPE, and do:
>>
>> IF(NOT DEFINED ${PROJECT_NAME}_BUILD_TYPE)
>>     SET(${PROJECT_NAME}_BUILD_TYPE "CUSTOM")
>> ENDIF()
>> SET(CMAKE_BUILD_TYPE "${${PROJECT_NAME}_BUILD_TYPE}")
>
> Alternatively, you might do:
>
> SET(${PROJECT_NAME}_BUILD_TYPE "CUSTOM"
>    CACHE STRING "${PROJECT_NAME} Build Type")
> SET(CMAKE_BUILD_TYPE "${${PROJECT_NAME}_BUILD_TYPE}")
>
> So, you'll have at least your project's own build type in the cache -
> and, thus, in the GUIs - along with the documenting comment while the
> cached value of CMAKE_BUILD_TYPE is still not the one that's actually
> used.
>
>> In this way, an undefined ${PROJECT_NAME}_BUILD_TYPE results in a
>> default CMAKE_BUILD_TYPE on behalf of the CMakeLists.txt file. Of
>> course, you should document that variable and urge your project's
>> users to not directly use CMAKE_BUILD_TYPE anymore; perhaps, you
>> should even hide the latter in a GUI by marking it as advanced.
>>
>> With regard to CMAKE_INSTALL_PREFIX, you could do the same - or use
>> CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT, as a robust criterion,
>> to see whether the user has supplied a value explicitly. Note that
>> there're additional aspects to consider if the CMakeLists.txt file
>> is to write that variable's value to the cache, cf. [1] et seq.
>>
>> Regards,
>>
>> Michael
> _______________________________________________
> 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
>



-- 
MSc Gabriel Petrovay
Mobile: +41(0)787978034
www.28msec.com


More information about the CMake mailing list