Trouble with non-standard CMAKE_BUILD_TYPE

[15knots]

Trouble with non-standard CMAKE_BUILD_TYPE

[15knots]

Option -DCMAKE_BUILD_TYPE:STRING=Debug is passed if your CDT build configuration is of DEBUG type. Just create a new CDT build configuration which is neither derived from DEBUG nor RELEASE type and use that.

[Krakonos]

Thanks. I tried that, but it seems I can only create new build configuration by deriving from others. The basic ones are Debug and Release, the others in "import" are in form of "Something > Debug" or "Something > Release". Deriving from them doesn't seem to do anything, as in "I can try to build it, but it has no effect, no directory is created, even the first time, and the build output contains specific parameters from the build I was trying before".

[15knots]

Concerning build configurations in the CDT UI, you are right. No chance to derive from nothing.

Why kind of workaround do you apply?.
If I set CMAKE_BUILD_TYPE to MySpecialBuildType on the CMake project settings Symbols tab, the CMake Console shows that that value is passed to cmake:
cmake -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_BUILD_TYPE:STRING=MySpecialBuildType -G "Unix Makefiles" ...
and in file /build/Debug/CMakeCache.txt I find the lines
//No help, variable specified on the command line. CMAKE_BUILD_TYPE:STRING=MySpecialBuildType

which is exactly what you might want.
Cmake simply ignores the first -DCMAKE_BUILD_TYPE:STRING=Debug option and none of the debug- or relase options is passed to the C-compiler. .

[15knots]

Closing this, since feedback was requested and no feedback arrived in more than one year. Re-open, if necessary.

[Krakonos]

Sorry for that! I'm not using eclipse myself and a colleague of mine did resolve it somehow, I think using an external script. I didn't have time or motivation to dig further. Keep it closed and thanks for your help, it was very much appreciated!

[sliwowitz]

I've just spent a couple hours trying to find out where do the default CMAKE_BUILD_TYPE definitions come from, and how to change them in order to compile a RelWithDebInfo type build. I'm fine with deriving my configuration from the "Default" one which does not specify any build type (overriding just seems a bit unclean), but it is inconsistent - there's no place to see the parameters in the configuration tabs, so one as to guess at the "magic" at work.

The magic seems convenient enough for most use cases I guess, so I probably wouldn't argue for changing the default behavior, but can this behavior be documented? A hint at the symbols tab explaining which symbols are being defined by cmake4eclipse, or a checkbox to show predefined options similar to "Show system variables" option in the standard build variables tab? (Or at least mention that somewhere in the help pages)

[15knots]

I've just spent a couple hours trying to find out where do the default CMAKE_BUILD_TYPE definitions come from, and how to change them in order to compile a RelWithDebInfo type build. I'm fine with deriving my configuration from the "Default" one which does not specify any build type (overriding just seems a bit unclean), but it is inconsistent - there's no place to see the parameters in the configuration tabs, so one as to guess at the "magic" at work.

The symbols specified in the symbols tab override those specified by cmake4eclipse.
So to do a RelWithDebInfo type build, just add a symbol named CMAKE_BUILD_TYPE in the symbols tab and give it the value you want. This will work for any build configuration.

Cmake4clipse adds the CMAKE_BUILD_TYPE symbol just for user convenience.
You will see the defined symbols in the first line (the cmake command-line) in the build console.

The magic seems convenient enough for most use cases I guess, so I probably wouldn't argue for changing the default behavior, but can this behavior be documented? A hint at the symbols tab explaining which symbols are being defined by cmake4eclipse, or a checkbox to show predefined options similar to "Show system variables" option in the standard build variables tab? (Or at least mention that somewhere in the help pages)

Mentioning in the help pages sounds reasonable.

[DennisSchiefer]

For people that might run into the same problem:

When you create a new build configuration, choose "Import predefined". This gives you, among others, three "CMake driven" options: Debug, Release, Default. The first two hard-code Debug/Release as build type. The last one does not define a build type and you have to do it yourself.

[15knots]

Am Do., 5. Nov. 2020 um 01:42 Uhr schrieb Dennis Schieferdecker < [email protected]>:

For people that might run into the same problem: When you create a new build configuration, choose "Import predefined". This gives you, among others, three "CMake driven" options: Debug, Release, Default. The first two hard-code Debug/Release as build type. The last one does not define a build type and you have

You might as well take any of the build configurations and add CMAKE_BUILD_TYPE as a symbol. That will override the default value.

[DennisSchiefer]

Yes, sorry. That works, too.
I just thought to bring it up, since some folks were confused which CMAKE_BUILD_TYPE would win if multiple show up on the command line (the latter) and the "Default" configuration (that I missed the first time around) handily avoids this question since it does not define a build type.

[inxksp]

Why can't you just pass the name of the current Eclipse configuration to CMAKE_BUILD_TYPE? This seems to be the most logical and convenient way.