summaryrefslogtreecommitdiff
path: root/support/misc
AgeCommit message (Collapse)Author
2019-06-02Update for 2019.05Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-04-15infra/utils: add helper to generate comma-separated listsYann E. MORIN
Add a helper macro that, from a space-separated list of items, returns a comma-separated list of the quoted items. This will be useful when we need to generate lists in JSON, later... Code suggested by Thomas P. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-03-04Update for 2019.02Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-01-16infra/pkg-cmake: use an obviously-invalid value for CMAKE_SYSTEM_VERSIONYann E. MORIN
In 36568732e4, we expanded toolchain.cmake to also define the value for CMAKE_SYSTEM_VERSION, as the cmake documentation states that it must be manually defined when doing cross-compilation [0]: When the CMAKE_SYSTEM_NAME variable is set explicitly to enable cross compiling then the value of CMAKE_SYSTEM_VERSION must also be set explicitly to specify the target system version. However, the fix in 36568732e4 uses the version of the kernel headers, assuming that would be the oldest kernel we could run on. Yet, this is not the case, because glibc (for example) has fallbacks to support running on kernels older than the headers it was built against. The cmake official wiki [1] additionally states: * CMAKE_SYSTEM_VERSION : optional, version of your target system, not used very much. Folllowed a little bit below, by: * CMAKE_TOOLCHAIN_FILE : absolute or relative path to a cmake script which sets up all the toolchain related variables mentioned above For instance for crosscompiling from Linux to Embedded Linux on PowerPC this file could look like this: # this one is important SET(CMAKE_SYSTEM_NAME Linux) #this one not so much SET(CMAKE_SYSTEM_VERSION 1) [...] Furthermore, using the kernel headers version can be a bit misleading (as it really looks like is is the correct version to use when it is not), while it is obvious that 1 is not really the output of `uname -r` and thus is definitely not misleading. Finally, random searches [2] about CMAKE_SYSTEM_VERSION, mostly only turns up issues related with Windows, Mac-OS, and to a lesser extent, Android (where it is forcibly set to 1), with issues realted to running under just Linux (as opposed to Adnroid) mostly non-existent. Consequently, we revert to using the value that is suggested in the cmake WiKi, i.e. 1, and which is basically what we also used as a workaround in the azure-iot-sdk-c paclkage up until d300b1d3b1. A case were we will need to have a real kernel version, is if we one day have a cmake-based pacakge that builds and installs a kernel module [3], because it will need the _running_ kernel version to install it in /lib/modules/VERSION/, but in that case it will anyway most probably not be the headers version. [0] https://cmake.org/cmake/help/v3.8/variable/CMAKE_SYSTEM_VERSION.html [1] https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/CrossCompiling [2] https://duckduckgo.com/?q=CMAKE_SYSTEM_VERSION [3] https://stackoverflow.com/questions/38205745/cmake-system-version-not-updated-for-new-kernel Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Samuel Martin <s.martin49@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-01-12package/pkg-cmake: add CMAKE_SYSTEM_VERSION to toolchainfile.cmakeArnout Vandecappelle (Essensium/Mind)
Quoting the CMake documentation: When the CMAKE_SYSTEM_NAME variable is set explicitly to enable cross compiling then the value of CMAKE_SYSTEM_VERSION must also be set explicitly to specify the target system version. Thus, we should also set CMAKE_SYSTEM_VERSION in toolchainfile.cmake. It is supposed to be set to the value of `uname -r` on the target. We don't have that exact value available (unless we build the kernel), but the value of BR2_TOOLCHAIN_HEADERS_AT_LEAST contains the (minimum) version of the kernel it will run on, so it should be OK for all practical purposes. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-12-01Update for 2018.11Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-09-07Merge branch 'next'Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-09-06Update for 2018.08Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-08-13support/misc: updating Vagrantfile to ubuntu 18.04Angelo Compagnucci
This patch updates the vagrant box to ubuntu bionic 64 and switches back to the official ubuntu image cause the issues with the official image are now solved. Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-07-19support/misc/toolchainfile.cmake.in: use TARGET_LDFLAGS for shared and ↵Damien Thébault
module libraries With cmake packages, we are only using TARGET_LDFLAGS for executables and not for shared libraries. This patch adds CMAKE_SHARED_LINKER_FLAGS and CMAKE_MODULE_LINKER_FLAGS to the cmake toolchain file so that buildroot TARGET_LDFLAGS are used for shared and module libraries. Signed-off-by: Damien Thébault <damien.thebault@vitec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-06-01Update for 2018.05Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-03-04Update for 2018.02Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-11-30Update for 2017.11Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-09-02Update for 2017.08Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-07-20support/scripts: relocate-sdk.sh now uses a normal pipe to find stringsWolfgang Grandegger
The normal shell does not support the bashism "< <(...)". Therefore we use a normal pipe to find files containing a specific string. Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-20support/scripts: relocate-sdk.sh now creates sdk-location in share/buildrootWolfgang Grandegger
This is because $(HOST_DIR)/usr is gone. Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-05pkg-cmake: programs are now installed in $(HOST_DIR)/binArnout Vandecappelle
Remove the redundant usr/ component of the HOST_DIR paths. Since a previous commit added a symlink from $(HOST_DIR)/usr to $(HOST_DIR), everything keeps on working. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-05pkg-cmake: move configuration files out of $(HOST_DIR)/usrArnout Vandecappelle
Move toolchainfile.cmake and Buildroot.cmake from $(HOST_DIR)/usr/share/buildroot to $(HOST_DIR)/share/buildroot. Build-tested with a bunch of cmake packages. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-04support/scripts: add relocate-sdk.sh script for SDK relocationWolfgang Grandegger
It will install the script "relocate-sdk.sh" in the HOST_DIR allowing to adjust the path to the SDK directory in all text files after it has been moved to a new location. Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> [Thomas: - Fix shebang to be /bin/sh instead of /bin/bash, suggested by Arnout - Use | instead of \ as a separator for sed expressions, suggested by Arnout, discussed with Wolfgang and others - Remove ./ at the beginning of LOCFILE, suggested by Arnout - Fix comment about the path check being made before doing the replacement, suggested by Arnout - Fix indentation, suggested by Arnout.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-06-14support/misc/target-dir-warning.txt: fix typoRahul Bedarkar
s/owernship/ownership/ Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-05-31Update for 2017.05Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-03-05core/pkg-cmake: better way to pass our CMAKE_MODULE_PATHYann E. MORIN
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-02support/cmake: impersonate a Linux system even moreYann E. MORIN
Some packages test the system name to decide whether to enable/disable features or link with specific libs. So we forcefully set the system name form our custom system file, so that packagses still believe they are running on Linux rather than Buildroot. Fixes: fastd : http://autobuild.buildroot.net/results/f1d/f1dfe90068ad62e733f17a22202235415bda3974/ paho-mqtt-c: http://autobuild.buildroot.net/results/457/457d76279e16247bf58c838a2c5dd0a4f3962c21/ libiio : http://autobuild.buildroot.net/results/281/2812b008a0ab6bab5fe4d45eb9ffe4e9496a8cb4/ and so on... Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reported-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Baruch Siach <baruch@tkos.co.il> Cc: Ben Boeckel <mathstuf@gmail.com> Cc: Jörg Krause <joerg.krause@embedded.rocks> Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Cc: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-01core/pkg-cmake: provide our own platform descriptionYann E. MORIN
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-28Update for 2017.02Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-02-26support/misc/Vagrantfile: reorganize provisioningAngelo Compagnucci
* Remove distribution upgrade cause it slows down the first boot and presents a bug when executed non interactively. * Reorganize provision scripts to be in privileged and non privileged sections * Add Ubuntu mirror automatic handling for apt packages sources Fixes bug #9581 Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-01-25Update for 2016.11.2Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-12-29Update for 2016.11.1Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-11-30Update for 2016.11Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-11-06pkg-cmake: Change -DNEBUG to -DNDEBUGStefan Nickl
Signed-off-by: Stefan Nickl <Stefan.Nickl@gmail.com> Acked-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-22toolchainfile.cmake: fix description of CMAKE_Fortran_FLAGS_{DEBUG,RELEASE}Thomas Petazzoni
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-22toochainfile.cmake: rework the way Buildroot sets flagsSamuel Martin
From the build configuration, Buildroot defines and set some compiler and linker flags that should be passed to any packages build-system. For package using the cmake-package infrastructure, this is achieved via the toolchainfile.cmake. This change simplifies the way the toolchainfile.cmake file handles these flags: it now just sets them, without any attempt to extend them with those Buildroot defined. This change still allows overriding these flags from the configure command line. So, now, when a CMake-based package needs to extend them, they should be fully set from the package *.mk file. This behavior is consistent with what is done for others package infrastructures. This change should not pull any regression WRT the bug #7280 [1]. However, now, when someone uses the toolchainfile.cmake file outside of Buildroot, he/she must overload all compiler/linker flags (including the ones Buildroot sets since they no longer get automatically added). [1] https://bugs.busybox.net/show_bug.cgi?id=7280 Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Samuel Martin <s.martin49@gmail.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-22toolchainfile.cmake: set per-config appended {C, CXX}FLAGSSamuel Martin
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-22package/pkg-cmake.mk: move CMAKE_BUILD_TYPE definition into toolchainfile.cmakeSamuel Martin
The chosen CMAKE_BUILD_TYPE encodes an option of the Buildroot configuration, so it makes more sense to save it in the toolchainfile.cmake than to pass it during configure. It is still possible to override the build type on the cmake command line. 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: reword description in the CHANGES file.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-19support/misc/Vagrantfile: bump to ubuntu 16.04Angelo Compagnucci
* Updating to ubuntu 16.04 * Fixing dependencies * Fixing locale complaints * Removing unused packages Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-16core: allow a br2-external tree to override a defconfigYann E. MORIN
Currently, it is not possible for a br2-external tree to override a defconfig bundled in Buildroot, nor is it possible to override one from a previous br2-external tree in the stack. However, it is interesting that a latter br2-external tree be able to override a defconfig: - the ones bundled in Buildroot are minimalist, and almost always build a toolchain, so a br2-external tree may want to provide a "better" defconfig (better, in the sense "suited for the project"); - similarly for a defconfig from a previous br2-external tree. But we can't do that, as the rules for the defconfigs are generated in the order the br2-external trees are specified, all after the bundled defconfigs. Those rule are patten-matching rules, which means that the first one to match is used, and the following ones are ignored. Add a new utility macro, 'reverse', inspired from GMSL, that does what it says: reverse a list of words. Use that macro to reverse the list of br2-external trees, so that the latters win over the formers, and even over bundled ones. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Samuel Martin <s.martin49@gmail.com> Cc: Romain Naour <romain.naour@openwide.fr> Cc: Julien CORJON <corjon.j@ecagroup.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-09-02Merge branch 'next'Peter Korsgaard
Quite some conflicts, so here goes .. Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-09-01Update for 2016.08Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-08-27core: move pkg-utils.mk to support/Yann E. MORIN
pkg-utils.mk contains various definitions that are used in the package infrastructures and packages themselves. However, those definitions can be useful in other parts of Buildroot, and are already used in a few places that are not related to the package infrastructure. Also, $(sep) will be needed early in the Makefile when we eventually support multiple br2-external trees. Since this file only contains definitions, we can include it anytime. So, consider that file to no longer be specific to the package infras: - move it to support and rename it, - move a few similar definitions from the main Makefile to that file. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-18pkg-cmake.mk: set CMAKE_SYSROOT variable in toolchainfile.cmakeSamuel Martin
This change enforces the CMAKE_SYSROOT value set in the toolchainfile.cmake. This fix overrides the CMake heuristics used to guess it, and turns off some non-desirable behavior adding "-isystem ..." flags to the compiler command line, misleading the compiler and making the build failed due to some unfound standard headers. Fixes: http://autobuild.buildroot.net/results/f7e/f7e92678e91a6cb15ccf32d4a7d75b39f49d6000/defconfig (and others) Cc: Ben Boeckel <mathstuf@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-03pkg-cmake.mk: export the fortran compiler path in the CMake toolchain fileSamuel Martin
Since the fortran support is conditional, only enable it when needed. Signed-off-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Cc: Benjamin Kamath <bkamath@spaceflight.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-31Update for 2016.05Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-01Update for 2016.02Peter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-02-04support/misc: Adding Vagrant file for provisioningAngelo Compagnucci
This patch adds a Vagrant file to buildroot. With this file you can provision a complete buildroot developing environment in minutes on all major platforms (Linux/Mac/Windows). [Peter: bump to 2GB RAM, hardcode Buildroot release, add unzip, drop website update and tweak manual text as suggested by Yann] Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-04package-cmake: remove now-redundant target ccache supportArnout Vandecappelle
All the complexity with the different ways that CMAKE_C_COMPILER and CMAKE_C_COMPILER_ARG1 can be set are no longer needed, it's all handled by the toolchain wrapper now. Note that it is still necessary to handle this for the host build. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-03-16toolchainfile.cmake: only search the sysroot for CMake moduleSamuel Martin
This change prevents CMake from searching outside the sysroot location for CMake modules when cross-compiling. Signed-off-by: Samuel Martin <s.martin49@gmail.com> Reviewed-by: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-12-09pkg-cmake.mk: Set CMAKE_SYSTEM_PROCESSOR.Volker Krause
This is rarely needed by packages, but convenient to have when it is. [Thomas: - don't define ARM_VARIANT as this name is too global, use CMAKE_SYSTEM_PROCESSOR_ARM_VARIANT instead. - don't use ifndef, but a more traditional else clause, for the non-ARM cases.] Signed-off-by: Volker Krause <volker.krause@kdab.com> Reviewed-by: Bernd Kuhls <bernd.kuhls@t-online.de> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Acked-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-09-28toolchainfile.cmake.in: do not force the CMAKE_{C, CXX}_FLAGS to the cacheSamuel Martin
Fix #7280 [1] When the FORCE option is passed to the set command, the variable is added/updated in the CMake cache every single time CMake processes this command. Because the toolchainfile.cmake prepends architecture/toolchain flags to the CMAKE_{C,CXX}_FLAGS, this makes the CFLAGS being updated in the generated Makefiles each time one reconfigures its project. So it forces the compilation of everything, even when nothing has changed. [1] https://bugs.busybox.net/show_bug.cgi?id=7280 Signed-off-by: Samuel Martin <s.martin49@gmail.com> Tested-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> (tested the SimpleApp reproduction scenario described in the bug report) Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-09-28toolchainfile.cmake.in: set linker flagsSamuel Martin
The linker flags are part of the toolchain configuration, so set them for the CMake-based packages. Signed-off-by: Samuel Martin <s.martin49@gmail.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-06-01pkg-cmake.mk: enable ccache for cmake packagesSamuel Martin
This patch updates the generated toolchainfile.cmake to use ccache. When toolchainfile.cmake is used inside Buildroot, using ccache during the build is driven by a CMake knob: USE_CCACHE, automatically set by the cmake-package infrastructure and reflecting the BR2_CCACHE value. Since this toolchainefile.cmake file can be used outside Buildroot, and this file also set a couple of things (among these: the sysroot cflag, some pkg-config environment variables), it is important to set the compiler variables as well to keep the consistency of the cross-compilation configuration. So, when it is used outside Buildroot, using ccache for the build is driven by the ccache program availability. Note that using ccache for the build is achieved by setting the *_ARG1 CMake variables to let CMake use ccache without failing in detecting the compiler. Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Samuel Martin <s.martin49@gmail.com> Cc: Luca Ceresoli <luca@lucaceresoli.net> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-26 21:09:40 +0000