On 03/07/2011 12:37 PM, Gabriel Petrovay wrote: > Thanks for the tips, Michael. > > We will do so, using project specific BUILD_TYPE and INSTALL_PREFIX.
However, the downside of this approach is that your project's users should not refer to the well-known CMake variables CMAKE_BUILD_TYPE and CMAKE_INSTALL_PREFIX anymore - possibly an issue to consider. > On Mon, Mar 7, 2011 at 12:20 PM, Michael Hertling <mhertl...@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. If you say SET(CMAKE_BUILD_TYPE "${${PROJECT_NAME}_BUILD_TYPE}" CACHE STRING "CMake Build Type" FORCE) here, the cached value of CMAKE_BUILD_TYPE will equal the value in the current scope again. Obviously, I'm quite unconcentrated today... ;-) >>> 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