[CMake] CMAKE_BUILD_TYPE does not work in CMAKE_TOOLCHAIN_FILE - how to proceed?

Hi, I'm new to cmake and we started using it to build proprietary embedded projects with a proprietary toolchain. We love the new build system's performance and its simplicity! Compared with what we were used to have, it is just superior in every aspect we met, really great! We hopefully based

Re: [CMake] CMAKE_BUILD_TYPE and exact control of compiler options

Hi, > - If not, what is the best/official way to get exact control over the compiler > and linker options used? I had to do something similar recently where I didn't want ``-DNDEBUG`` to be in any of the configurations. I used ``CMAKE_USER_MAKE_RULES_OVERRIDE `` to set the path to file

Re: [CMake] CMAKE_BUILD_TYPE and exact control of compiler options

Dan Liew wrote: > Hi, > > >> - If not, what is the best/official way to get exact control over the >> compiler and linker options used? > > I had to do something similar recently where I didn't want > ``-DNDEBUG`` to be in any of the configurations. > > I used

Re: [CMake] CMAKE_BUILD_TYPE and exact control of compiler options

René J. V. Bertin wrote: Similarly, is there a way to set preprocessor variables (cf. https://cmake.org/Bug/view.php?id=12928 which has been silent for a long time)? One could do -DINCLUDE_DIRECTORIES=${CPPFLAGS}, but that may lead to unexpected results if CPPFLAGS contains something other

[CMake] CMAKE_BUILD_TYPE and exact control of compiler options

Hello, I'm using cmake in conjunction with a packaging/distribution system that aims to control the compiler and linker flags, a priori via the usual environment variables. (We're talking about MacPorts.) Using one of the CMAKE_BUILD_TYPE presets, the value of those env. variables appears at

Re: [CMake] CMAKE_BUILD_TYPE and exact control of compiler options

Hi, On Mon, Oct 12, 2015 at 10:39 AM, René J. V. wrote: > Hello, > > I'm using cmake in conjunction with a packaging/distribution system that > aims to > control the compiler and linker flags, a priori via the usual environment > variables. (We're talking about MacPorts.) >

Re: [CMake] CMAKE_BUILD_TYPE and exact control of compiler options

Andreas Pakulat wrote: > No this is not possible in general. A CMakeLists.txt file can always just > set their own compiler/linker flags. Which would require patching each and every one of them, which isn't exactly desirable. >> - Out of curiosity, what's special about the

Re: [CMake] CMAKE_BUILD_TYPE case sensitivity

I see that this CMake variable is not case-sensitive at it and defaults to DEBUG. I'm afraid this is incorrect; the default build type is empty. When you build with Release, the flag NDEBUG is set; when you build with Debug the DEBUG flag is set. -- Powered by www.kitware.com Visit other

[CMake] CMAKE_BUILD_TYPE case sensitivity

Is the CMAKE_BUILD_TYPE case sensitive. I have seen references to both Debug and DEBUG in the mailing lists. Thanks, -Anil -- 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] CMAKE_BUILD_TYPE and flags (special case)

Hi everyone I'm trying to build a custom (C++) library using cmake 2.8.4, mingw32 and intel compiler (icl) on a win7-32 machine, but CMAKE_BUILD_TYPE is not being respected: it's using the debug flags when building with mingw. I've tried setting this variable to Release both with the cache editor

Re: [CMake] CMAKE_BUILD_TYPE and flags (special case)

If anyone's interested: got it working using MinSizeRel For now, at least 2011/11/24 Felipe Lema felipe.l...@alges.cl Hi everyone I'm trying to build a custom (C++) library using cmake 2.8.4, mingw32 and intel compiler (icl) on a win7-32 machine, but CMAKE_BUILD_TYPE is not being

[CMake] CMake_BUILD_TYPE not imported to XCode 4.0.1

Dear CMake list, when building external libraries such as ITK, VTK, etc. from source, XCode 4.0.1 is not able to import the BuildType parameter set in Cmake 2.8-4. When setting CMAKE_BUILD_TYPE = Release, still XCode uses Debug as build type. Has someone else observed this behavior?

Re: [CMake] CMake_BUILD_TYPE not imported to XCode 4.0.1

On 06/21/2011 03:31 PM, Ignaz Reicht wrote: Dear CMake list, when building external libraries such as ITK, VTK, etc. from source, XCode 4.0.1 is not able to import the BuildType parameter set in Cmake 2.8-4. When setting CMAKE_BUILD_TYPE = Release, still XCode uses Debug as build type. Has

Re: [CMake] CMake_BUILD_TYPE not imported to XCode 4.0.1

thank you Am 21.06.2011 um 16:07 schrieb Michael Wild: On 06/21/2011 03:31 PM, Ignaz Reicht wrote: Dear CMake list, when building external libraries such as ITK, VTK, etc. from source, XCode 4.0.1 is not able to import the BuildType parameter set in Cmake 2.8-4. When setting

Re: [CMake] CMAKE_BUILD_TYPE should start as a drop-list option

The second line seems like a good idea to me. The user can always modify the property in their code if they have custom build types. The first line seems like a bad idea. I think the default build type should be left to the project. Currently you can set it manually before project(). I think

[CMake] CMAKE_BUILD_TYPE should start as a drop-list option

set(CMAKE_BUILD_TYPE Debug CACHE STRING Set build type) set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS Debug Release MinSizeRel RelWithDebInfo) This could be added to some default startup macro, no? ___ Powered by

[CMake] CMAKE_BUILD_TYPE and Makefiles

Am I correct in thinking that cmake doesn't support build types for make files? It doesn't seem to matter what I do with CMAKE_CONFIGURATION_TYPES, when I generate a set of make files, they appear to be created for a single generic target. Is there a 'canonical' way of coaxing cmake to generate

Re: [CMake] CMAKE_BUILD_TYPE does not work correctly for Linux and CMake-2.4.6

On 2007-04-01 13:59-0700 Alan W. Irwin wrote: I have found two bugs in compiler flag support for Linux that I would like to discuss here before making formal bug reports. 1. A general compiler flag bug with ENABLE_LANGUAGE. The combination PROJECT(free_eos CXX) ENABLE_LANGUAGE(C) defines

[CMake] CMAKE_BUILD_TYPE does not work correctly for Linux and CMake-2.4.6

I have found two bugs in compiler flag support for Linux that I would like to discuss here before making formal bug reports. 1. A general compiler flag bug with ENABLE_LANGUAGE. By accident while investigating the second fortran-related compiler flag bug below, I also happened an

Re: [CMake] CMAKE_BUILD_TYPE

Brandon J. Van Every wrote: Bill Hoffman wrote: Basically, there are two types of generators, single build type per build tree, and multi- build type per tree. The variables that are useful for that are here: CMAKE_BUILD_TYPE is used by makefile generators or any future generator that

Re: [CMake] CMAKE_BUILD_TYPE

Bill Hoffman wrote: Brandon J. Van Every wrote: So I am not seeing how Debug is a default value for CMAKE_BUILD_TYPE. OK, it seems that it is the default for nmake with cl, That's consistent with Windows build culture, in that a MSVC .sln file does have Debug as the default. I don't

[CMake] CMAKE_BUILD_TYPE

I added the following notation to the Useful Variables page of the wiki: http://www.cmake.org/Wiki/CMake_Useful_Variables#Compilers_and_Tools Note that CMAKE_BUILD_TYPE is not initialized with a readable value at configuration time. This is because the user is free to select a build type at

Re: [CMake] CMAKE_BUILD_TYPE

Brandon J. Van Every wrote: I added the following notation to the Useful Variables page of the wiki: http://www.cmake.org/Wiki/CMake_Useful_Variables#Compilers_and_Tools Note that CMAKE_BUILD_TYPE is not initialized with a readable value at configuration time. This is because the user is free

Re: [CMake] CMAKE_BUILD_TYPE

Bill Hoffman wrote: Basically, there are two types of generators, single build type per build tree, and multi- build type per tree. The variables that are useful for that are here: CMAKE_BUILD_TYPE is used by makefile generators or any future generator that supports one build type per