--===============1080905801== Content-Type: multipart/alternative; boundary=001a1139718a4037b20521e75503 --001a1139718a4037b20521e75503 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On Mon, Oct 12, 2015 at 10:39 AM, Ren=C3=A9 J. V. wro= te: > 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, fo= r > instance). > > Experimenting with -DCMAKE_BUILD_TYPE=3DMacPorts in the toplevel control = file > (cmake PortGroup), that appeared indeed to work, but I appear to have bee= n > 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 flag= s > 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=3DDebian bu= ild > 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 --001a1139718a4037b20521e75503 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On Mon, Oct 12, 2015 at 10:39 AM, Ren=C3=A9 J. V. <= rjvbertin@gmail.co= m> wrote:
Hello,

I'm using cmake in conjunction with a packaging/distribution system tha= t 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. variable= s
appears at most to be added in front of the preset options, which means use= r
options can be overridden. That may be intended behaviour, but not ideal fo= r my
use case.

Working with Debian and Ubuntu systems, I deduced that using a non-pre-defi= ned
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<= br> instance).

Experimenting with -DCMAKE_BUILD_TYPE=3DMacPorts in the toplevel control fi= le
(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 h= as
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 compi= ler
and linker options used?

No this is no= t 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 d= oable with a toolchain file. These are usually used to teach CMake speciali= ties about compilers/linkers that it does not support itself and behave suf= ficiently different from one it does know. That is for example gcc builds f= or doing cross-compilation to some specialized hardware may not work with c= ertain flags CMake uses by default for gcc builds.

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

There's no such build t= ype in CMake, see the Compilers and Tools section here:=C2=A0https://cmake.o= rg/Wiki/CMake_Useful_Variables#Various_Options that details the built-i= n types in CMake.

Andreas
--001a1139718a4037b20521e75503-- --===============1080905801== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- 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 --===============1080905801==--