[prev in list] [next in list] [prev in thread] [next in thread]
List: cmake
Subject: Re: [CMake] CMAKE_BUILD_TYPE and exact control of compiler options
From: Andreas Pakulat <apaku () gmx ! de>
Date: 2015-10-12 12:18:54
Message-ID: CAExHGmR_nh5g5xB7arMg0yGGGWVL6h-cj+YJjgouxN3YXPc4xA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi,
On Mon, Oct 12, 2015 at 10:39 AM, René J. V. <rjvbertin@gmail.com> 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
[Attachment #5 (text/html)]
<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct \
12, 2015 at 10:39 AM, René J. V. <span dir="ltr"><<a \
href="mailto:rjvbertin@gmail.com" target="_blank">rjvbertin@gmail.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hello,<br>
<br>
I'm using cmake in conjunction with a packaging/distribution system that aims \
to<br> control the compiler and linker flags, a priori via the usual environment<br>
variables. (We're talking about MacPorts.)<br>
<br>
Using one of the CMAKE_BUILD_TYPE presets, the value of those env. variables<br>
appears at most to be added in front of the preset options, which means user<br>
options can be overridden. That may be intended behaviour, but not ideal for my<br>
use case.<br>
<br>
Working with Debian and Ubuntu systems, I deduced that using a non-pre-defined<br>
BUILD_TYPE make cmake use the values of CFLAGS, CXXFLAGS etc, through<br>
CMAKE_C_FLAGS, CMAKE_CXX_FLAGS etc (instead of CMAKE_C*_FLAGS_RELEASE, for<br>
instance).<br>
<br>
Experimenting with -DCMAKE_BUILD_TYPE=MacPorts in the toplevel control file<br>
(cmake PortGroup), that appeared indeed to work, but I appear to have been<br>
mistaken. Adding -DCMAKE_C*_FLAGS_MACPORTS definitions has no effect, nor has<br>
setting CMAKE_C*_FLAGS from the CMake command line.<br>
<br>
Which leads me to the following questions:<br>
- Is it indeed possible to get CMake to take all compiler and linker flags from<br>
the environment, and if so, how?</blockquote><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- If not, what is the best/official way to get exact control over the compiler<br>
and linker options used?</blockquote><div><div><br></div><div>No this is not possible \
in general. A CMakeLists.txt file can always just set their own compiler/linker \
flags.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- Out of curiosity, what's special about the CMAKE_BUILD_TYPE=Debian build \
type?<br></blockquote><div><br></div><div>There's no such build type in CMake, \
see the Compilers and Tools section here: <a \
href="https://cmake.org/Wiki/CMake_Useful_Variables#Various_Options">https://cmake.org/Wiki/CMake_Useful_Variables#Various_Options</a> \
that details the built-in types in \
CMake.</div><div><br></div><div>Andreas</div></div></div></div>
--
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic