CMAKE_BUILD_TYPE and exact control of compiler options

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

CMAKE_BUILD_TYPE and exact control of compiler options

René J. V.  Bertin
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 most to be added in front of the preset options, which means user
options can be overridden. That may be intended behaviour, but not ideal for my
use case.

Working with Debian and Ubuntu systems, I deduced that using a non-pre-defined
BUILD_TYPE make cmake use the values of CFLAGS, CXXFLAGS etc, through
CMAKE_C_FLAGS, CMAKE_CXX_FLAGS etc (instead of CMAKE_C*_FLAGS_RELEASE, for
instance).

Experimenting with -DCMAKE_BUILD_TYPE=MacPorts in the toplevel control file
(cmake PortGroup), that appeared indeed to work, but I appear to have been
mistaken. Adding -DCMAKE_C*_FLAGS_MACPORTS definitions has no effect, nor has
setting CMAKE_C*_FLAGS from the CMake command line.

Which leads me to the following questions:
- Is it indeed possible to get CMake to take all compiler and linker flags from
the environment, and if so, how?
- If not, what is the best/official way to get exact control over the compiler
and linker options used?
- Out of curiosity, what's special about the CMAKE_BUILD_TYPE=Debian build type?

Thanks
René Bertin

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: CMAKE_BUILD_TYPE and exact control of compiler options

René J. V.  Bertin
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 than -I options.

R.

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: CMAKE_BUILD_TYPE and exact control of compiler options

Andreas Pakulat-2
In reply to this post by René J. V. Bertin
Hi,

On Mon, Oct 12, 2015 at 10:39 AM, René J. V. <[hidden email]> 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.)

Using one of the CMAKE_BUILD_TYPE presets, the value of those env. variables
appears at most to be added in front of the preset options, which means user
options can be overridden. That may be intended behaviour, but not ideal for my
use case.

Working with Debian and Ubuntu systems, I deduced that using a non-pre-defined
BUILD_TYPE make cmake use the values of CFLAGS, CXXFLAGS etc, through
CMAKE_C_FLAGS, CMAKE_CXX_FLAGS etc (instead of CMAKE_C*_FLAGS_RELEASE, for
instance).

Experimenting with -DCMAKE_BUILD_TYPE=MacPorts in the toplevel control file
(cmake PortGroup), that appeared indeed to work, but I appear to have been
mistaken. Adding -DCMAKE_C*_FLAGS_MACPORTS definitions has no effect, nor has
setting CMAKE_C*_FLAGS from the CMake command line.

Which leads me to the following questions:
- Is it indeed possible to get CMake to take all compiler and linker flags from
the environment, and if so, how?
- If not, what is the best/official way to get exact control over the compiler
and linker options used?

No this is not possible in general. A CMakeLists.txt file can always just set their own compiler/linker flags.

However if I understand you correctly (in what kind of flags you want to change), then this could be doable with a toolchain file. These are usually used to teach CMake specialities about compilers/linkers that it does not support itself and behave sufficiently different from one it does know. That is for example gcc builds for doing cross-compilation to some specialized hardware may not work with certain flags CMake uses by default for gcc builds.

The toolchain files are just cmake scripts, you can see some examples in the Modules/Platform directory of your cmake install. They set certain special variables that CMake will read out again when creating compiler/linker commandlines. The variables are explained in the documentation of CMake IIRC.
 
- Out of curiosity, what's special about the CMAKE_BUILD_TYPE=Debian build type?

There's no such build type in CMake, see the Compilers and Tools section here: https://cmake.org/Wiki/CMake_Useful_Variables#Various_Options that details the built-in types in CMake.

Andreas

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: CMAKE_BUILD_TYPE and exact control of compiler options

René J. V.  Bertin
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 CMAKE_BUILD_TYPE=Debian build
>> type?
>>
>
> There's no such build type in CMake, see the Compilers and Tools section
> here: https://cmake.org/Wiki/CMake_Useful_Variables#Various_Options that
> details the built-in types in CMake.

I know it doesn't exist as a preset in CMake. But take a look at the CMake files
shipped with KDE4's kdelibs: those actually introduce CMAKE_C*_FLAGS_DEBIAN
variables (in addition to using specific install locations, for instance).
It's quite important that there is such a feature: configure and its alternatives
are supposed to take CFLAGS, CXXFLAGS and family into consideration (or at least
should have a mode in which they do, IMVHO).

I suppose that what happens is that requesting an unknown CMAKE_BUILD_TYPE is
equivalent to not requesting one at all, and also prevents downstream CMake files
to pick a default preset if CMAKE_BUILD_TYPE hasn't been defined by the caller.
I've had a better look at the control file I mentioned, and found the reason why
$CFLAGS and $CXXFLAGS weren't being used.

It turns out that if you set CMAKE_CXX_FLAGS on the commandline, it is no longer
set to include $CXXFLAGS from the environment. Comments in the control file
suggest that that wasn't always the case.

R.

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: CMAKE_BUILD_TYPE and exact control of compiler options

Dan Liew
In reply to this post by René J. V. Bertin
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
containing overrides, this must be set before calling ``project()``

```
set(CMAKE_USER_MAKE_RULES_OVERRIDE
${CMAKE_CURRENT_SOURCE_DIR}/cmake/c_flags_override.cmake)
project(ABC C)
```

The contents of ``c_flags_override.cmake`` looks like this

```
if (("${CMAKE_C_COMPILER_ID}" MATCHES "Clang") OR
("${CMAKE_C_COMPILER_ID}" MATCHES "GNU"))
# Taken from Modules/Compiler/GNU.cmake but -DNDEBUG is removed
  set(CMAKE_C_FLAGS_INIT "")
  set(CMAKE_C_FLAGS_DEBUG_INIT "-g")
  set(CMAKE_C_FLAGS_MINSIZEREL_INIT "-Os")
  set(CMAKE_C_FLAGS_RELEASE_INIT "-O3")
  set(CMAKE_C_FLAGS_RELWITHDEBINFO_INIT "-O2 -g")
else()
  message(FATAL_ERROR "Overrides not set for compiler ${CMAKE_C_COMPILER_ID}")
endif()
```

I'm not sure if this is really the correct route to go down though for
your use case.

Dan.
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: CMAKE_BUILD_TYPE and exact control of compiler options

René J. V.  Bertin
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  ``CMAKE_USER_MAKE_RULES_OVERRIDE `` to set the path to file
> containing overrides, this must be set before calling ``project()``

> I'm not sure if this is really the correct route to go down though for
> your use case.

That wouldn't be impossible. A more generic way to achieve what you did, one
that doesn't require patching "client" CMake files (which I find unacceptable):

Store the customised settings in a file (I'd call it cmake.initcache) and call
cmake as

%> cmake -C./cmake.initcache "$@"

This is an approach I follow with a more basic building workflow of my own, one
where I keep localised/customised settings (CC/CXX, CFLAGS/CXXFLAGS, LDFLAGS
etc) in a ./wconfigure.env file, which is parsed by wrappers to configure and
cmake. It's not a usual approach for MacPorts, though.

R.

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake