2014-06-01 11:24:23 +02:00
|
|
|
#
|
|
|
|
|
# Automatically generated file; DO NOT EDIT.
|
|
|
|
|
# CMake toolchain file for Buildroot
|
|
|
|
|
#
|
|
|
|
|
|
2014-06-01 11:24:24 +02:00
|
|
|
# In order to allow the toolchain to be relocated, we calculate the
|
2017-07-04 16:04:01 +02:00
|
|
|
# HOST_DIR based on this file's location: $(HOST_DIR)/share/buildroot
|
2014-06-01 11:24:24 +02:00
|
|
|
# and store it in RELOCATED_HOST_DIR.
|
|
|
|
|
# All the other variables that need to refer to HOST_DIR will use the
|
|
|
|
|
# RELOCATED_HOST_DIR variable.
|
2017-07-04 16:04:01 +02:00
|
|
|
string(REPLACE "/share/buildroot" "" RELOCATED_HOST_DIR ${CMAKE_CURRENT_LIST_DIR})
|
2014-06-01 11:24:24 +02:00
|
|
|
|
core/pkg-cmake: better way to pass our CMAKE_MODULE_PATH
Currently, we tell cmake where to look for our own custom platform
description by passing the path to the moduls directory on the command
line.
However, this causes two different problems.
First, some packages simply set CMAKE_MODULE_PATH in their
CMakeList.txt, thus overriding our own path, and then our platform
description is not found.
Second, cmake may internally call sub-cmake (e.g. in the try_compile
macro), but the CMAKE_MODULE_PATH is not automatically passed down in
this case.
For the first problem, we could hunt down and fix all offenders, but
this is an endless endeavour, especially since packagers are told to do
so on the cmake wiki [0]:
CMAKE_MODULE_PATH
tell CMake to search first in directories listed in
CMAKE_MODULE_PATH when you use FIND_PACKAGE() or INCLUDE()
SET(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/MyCMakeScripts)
FIND_PACKAGE(HelloWorld)
The second problem could be solved by passing yet another variable on
the command line, that tells cmake to explicitly pass arbitrary
variables down to sub-cmake calls:
-DCMAKE_TRY_COMPILE_PLATFORM_VARIABLES=CMAKE_MODULE_PATH
However, this only covers the case of try_compile. Even though no other
case is known yet, we'd still risk missing locations where we would need
to propagate CMAKE_MODULE_PATH, even some where we'd have no solution
like for try_compile.
Instead, ngladitz on IRC suggested that CMAKE_MODULE_PATH be set
directly from the toolchain file.
And indeed this fixes both problems explained above.
So be it.
[0] https://cmake.org/Wiki/CMake_Useful_Variables
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Cc: Ben Boeckel <mathstuf@gmail.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-04 18:28:44 +01:00
|
|
|
# Point cmake to the location where we have our custom modules,
|
|
|
|
|
# so that it can find our custom platform description.
|
|
|
|
|
list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_LIST_DIR})
|
|
|
|
|
|
core/pkg-cmake: provide our own platform description
The handling of RPATH in cmake-3.7 has changed drastically, causing a
slew of build failures dues to libraries from the host being pulled in:
- domoticz : http://autobuild.buildroot.org/results/fd0/fd0ba54c7abf973691b39a0ca1bb4e07d749593a/
- freerdp : http://autobuild.buildroot.org/results/5d4/5d429d0e288754a541ee5d8be515454c5fccd28b/
- libcec : http://autobuild.buildroot.org/results/3f3/3f3593bab7734dd274faf5b5690895e9424cbb89/
- and so on...
The bug was reported upstream [0], which dismissed it altogether [1] as
being expected behaviour, quoting:
I don't think there is anything wrong with that change on its own.
It merely exposed some existing behavior in a new case.
Instead, upstream suggested in that same message that a platform
definition be used instead, quoting:
If a toolchain file specifies CMAKE_SYSTEM_NAME such that a custom
`Platform/MySystem.cmake` file is loaded then the latter can set
them as needed for the target platform.
So here we are doing so:
- we add a new platfom definitions that inherits from the Linux one,
then overrides the problematic settings;
- we change our toolchain file to use that platform instead;
- we tell cmake where to find additional modules, so that it can find
our custom platform file.
This has been tested to work in the following conditions:
- pre-installed host cmake, versions 3.5.1 (Ubuntu 16.04) and 3.7.2
(manually built)
- internal cmake, versions 3.6.3 (the current version as of this
patch) and 3.7.2 (with the followup patches).
Thanks to Jörg, Ben and Baruch for the help investigating the issue.
Special thanks to Jörg for handling the discussion with upstream and
pointing to the relevant messages! :-)
[0] http://public.kitware.com/pipermail/cmake/2017-February/064970.html
[1] http://public.kitware.com/pipermail/cmake/2017-February/065063.html
To be noted: Thomas suggested we set these directly in the toolchain
file. Unfortunately, wherever we put those settings in the toolchain
file, this does not work.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Cc: Ben Boeckel <mathstuf@gmail.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-28 19:07:22 +01:00
|
|
|
set(CMAKE_SYSTEM_NAME Buildroot)
|
2014-11-17 21:02:41 +01:00
|
|
|
set(CMAKE_SYSTEM_PROCESSOR @@CMAKE_SYSTEM_PROCESSOR@@)
|
2014-06-01 11:24:23 +02:00
|
|
|
|
toolchainfile.cmake: set per-config appended {C, CXX}FLAGS
When a build type is set, CMake does append some flags that can override
those set by Buildroot due to the gcc option parser (in which the last
argument controling an option wins).
Hereafter is a summary of the optimization and debug flags set by
Buildroot and appended by CMake.
* Flags set by Buildroot depending on the configuration:
BR2_ENABLE_DEBUG | Optim. level | Buildroot {C,CXX}FLAGS
=================+=====================+=======================
y | BR2_OPTIMIZE_S | -Os -gx
y | BR2_OPTIMIZE_G | -Og -gx
y | BR2_OPTIMIZE_{0..3} | -On -gx
n | BR2_OPTIMIZE_S | -Os
n | BR2_OPTIMIZE_G | -Og
n | BR2_OPTIMIZE_{0..3} | -On
* Default flags appended by CMake depending on the build type:
Build type | Flags | Effects on {C,CXX}FLAGS
===============+=================+===========================================
Debug | -g | Force -g, compatible with BR2_ENABLE_DEBUG
MinSizeRel | -Os -DNDEBUG | Set -Os, compatible with BR2_OPTIMIZE_S
Release | -O3 -DNDEBUG | Set -O3, closest to the others cases,
| | though the optimization level is forced.
RelWithDebInfo | -O2 -g -DNDEBUG | Force -g and set -O2, not friendly with BR
To avoid the CMake flags take precedence over the Buildroot ones, this
change sets in toolchainfile.cmake the per-config compiler flags CMake
can append depending on the build type Buildroot defined.
So, CMake does not mess up with the compilation flags Buildroot sets.
It is still possible to override these per-config flags on the cmake
command line.
Note:
If a CMake-based project forces the compiler and/or linker flag
definitions (the default ones or the per-config ones - e.g.
CMAKE_C_FLAGS/CMAKE_C_FLAGS_{DEBUG,RELEASE}), there is not much
Buildroot can do about it.
So, the flags will be overwritten anyway in these cases.
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Thomas:
- adjust comment in toolchainfile.cmake.in, as suggested by Arnout.
- also handle CMAKE_Fortran_FLAGS_*, as suggested by Arnout.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-16 13:12:39 +02:00
|
|
|
# Set the {C,CXX}FLAGS appended by CMake depending on the build type
|
|
|
|
|
# defined by Buildroot. CMake defaults these variables with -g and/or
|
|
|
|
|
# -O options, and they are appended at the end of the argument list,
|
|
|
|
|
# so the Buildroot options are overridden. Therefore these variables
|
|
|
|
|
# have to be cleared, so that the options passed in CMAKE_C_FLAGS do
|
|
|
|
|
# apply.
|
|
|
|
|
#
|
|
|
|
|
# Note:
|
|
|
|
|
# if the project forces some of these flag variables, Buildroot is
|
|
|
|
|
# screwed up and there is nothing Buildroot can do about that :(
|
|
|
|
|
set(CMAKE_C_FLAGS_DEBUG "" CACHE STRING "Debug CFLAGS")
|
|
|
|
|
set(CMAKE_CXX_FLAGS_DEBUG "" CACHE STRING "Debug CXXFLAGS")
|
2016-11-06 21:05:13 +01:00
|
|
|
set(CMAKE_C_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release CFLAGS")
|
|
|
|
|
set(CMAKE_CXX_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release CXXFLAGS")
|
toolchainfile.cmake: set per-config appended {C, CXX}FLAGS
When a build type is set, CMake does append some flags that can override
those set by Buildroot due to the gcc option parser (in which the last
argument controling an option wins).
Hereafter is a summary of the optimization and debug flags set by
Buildroot and appended by CMake.
* Flags set by Buildroot depending on the configuration:
BR2_ENABLE_DEBUG | Optim. level | Buildroot {C,CXX}FLAGS
=================+=====================+=======================
y | BR2_OPTIMIZE_S | -Os -gx
y | BR2_OPTIMIZE_G | -Og -gx
y | BR2_OPTIMIZE_{0..3} | -On -gx
n | BR2_OPTIMIZE_S | -Os
n | BR2_OPTIMIZE_G | -Og
n | BR2_OPTIMIZE_{0..3} | -On
* Default flags appended by CMake depending on the build type:
Build type | Flags | Effects on {C,CXX}FLAGS
===============+=================+===========================================
Debug | -g | Force -g, compatible with BR2_ENABLE_DEBUG
MinSizeRel | -Os -DNDEBUG | Set -Os, compatible with BR2_OPTIMIZE_S
Release | -O3 -DNDEBUG | Set -O3, closest to the others cases,
| | though the optimization level is forced.
RelWithDebInfo | -O2 -g -DNDEBUG | Force -g and set -O2, not friendly with BR
To avoid the CMake flags take precedence over the Buildroot ones, this
change sets in toolchainfile.cmake the per-config compiler flags CMake
can append depending on the build type Buildroot defined.
So, CMake does not mess up with the compilation flags Buildroot sets.
It is still possible to override these per-config flags on the cmake
command line.
Note:
If a CMake-based project forces the compiler and/or linker flag
definitions (the default ones or the per-config ones - e.g.
CMAKE_C_FLAGS/CMAKE_C_FLAGS_{DEBUG,RELEASE}), there is not much
Buildroot can do about it.
So, the flags will be overwritten anyway in these cases.
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Thomas:
- adjust comment in toolchainfile.cmake.in, as suggested by Arnout.
- also handle CMAKE_Fortran_FLAGS_*, as suggested by Arnout.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-16 13:12:39 +02:00
|
|
|
|
2016-10-16 13:12:38 +02:00
|
|
|
# Build type from the Buildroot configuration
|
|
|
|
|
set(CMAKE_BUILD_TYPE @@CMAKE_BUILD_TYPE@@ CACHE STRING "Buildroot build configuration")
|
|
|
|
|
|
2016-10-16 13:12:45 +02:00
|
|
|
# Buildroot defaults flags.
|
|
|
|
|
# If you are using this toolchainfile.cmake file outside of Buildroot and
|
|
|
|
|
# want to customize the compiler/linker flags, then:
|
|
|
|
|
# * set them all on the cmake command line, e.g.:
|
|
|
|
|
# cmake -DCMAKE_C_FLAGS="@@TARGET_CFLAGS@@ -Dsome_custom_flag" ...
|
2016-11-06 21:05:13 +01:00
|
|
|
# * and make sure the project's CMake code extends them like this if needed:
|
2016-10-16 13:12:45 +02:00
|
|
|
# set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Dsome_definitions")
|
|
|
|
|
set(CMAKE_C_FLAGS "@@TARGET_CFLAGS@@" CACHE STRING "Buildroot CFLAGS")
|
|
|
|
|
set(CMAKE_CXX_FLAGS "@@TARGET_CXXFLAGS@@" CACHE STRING "Buildroot CXXFLAGS")
|
|
|
|
|
set(CMAKE_EXE_LINKER_FLAGS "@@TARGET_LDFLAGS@@" CACHE STRING "Buildroot LDFLAGS for executables")
|
|
|
|
|
|
2014-06-01 11:24:23 +02:00
|
|
|
set(CMAKE_INSTALL_SO_NO_EXE 0)
|
|
|
|
|
|
2017-07-04 16:04:02 +02:00
|
|
|
set(CMAKE_PROGRAM_PATH "${RELOCATED_HOST_DIR}/bin")
|
2016-08-17 23:19:36 +02:00
|
|
|
set(CMAKE_SYSROOT "${RELOCATED_HOST_DIR}/@@STAGING_SUBDIR@@")
|
2014-06-01 11:24:24 +02:00
|
|
|
set(CMAKE_FIND_ROOT_PATH "${RELOCATED_HOST_DIR}/@@STAGING_SUBDIR@@")
|
2014-06-01 11:24:23 +02:00
|
|
|
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
|
2015-03-08 10:47:22 +01:00
|
|
|
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
|
2014-06-01 11:24:23 +02:00
|
|
|
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
|
|
|
|
|
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
|
2014-06-01 11:24:24 +02:00
|
|
|
set(ENV{PKG_CONFIG_SYSROOT_DIR} "${RELOCATED_HOST_DIR}/@@STAGING_SUBDIR@@")
|
2014-06-01 11:24:23 +02:00
|
|
|
|
2014-06-01 11:24:25 +02:00
|
|
|
# This toolchain file can be used both inside and outside Buildroot.
|
2015-10-04 14:28:53 +02:00
|
|
|
set(CMAKE_C_COMPILER "${RELOCATED_HOST_DIR}/@@TARGET_CC@@")
|
|
|
|
|
set(CMAKE_CXX_COMPILER "${RELOCATED_HOST_DIR}/@@TARGET_CXX@@")
|
2016-07-03 15:47:43 +02:00
|
|
|
if(@@TOOLCHAIN_HAS_FORTRAN@@)
|
2016-10-22 16:44:06 +02:00
|
|
|
set(CMAKE_Fortran_FLAGS_DEBUG "" CACHE STRING "Debug Fortran FLAGS")
|
2016-11-06 21:05:13 +01:00
|
|
|
set(CMAKE_Fortran_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release Fortran FLAGS")
|
2016-10-16 13:12:45 +02:00
|
|
|
set(CMAKE_Fortran_FLAGS "@@TARGET_FCFLAGS@@" CACHE STRING "Buildroot FCFLAGS")
|
2016-07-03 15:47:43 +02:00
|
|
|
set(CMAKE_Fortran_COMPILER "${RELOCATED_HOST_DIR}/@@TARGET_FC@@")
|
|
|
|
|
endif()
|
