buildroot/support/misc, branch 2016.11

Update for 2016.11

2016-11-30T22:16:22+00:00

Signed-off-by: Peter Korsgaard

pkg-cmake: Change -DNEBUG to -DNDEBUG

2016-11-06T21:30:40+00:00

Signed-off-by: Stefan Nickl Acked-by: Samuel Martin Signed-off-by: Thomas Petazzoni

toolchainfile.cmake: fix description of CMAKE_Fortran_FLAGS_{DEBUG,RELEASE}

2016-10-22T14:44:06+00:00

Signed-off-by: Thomas Petazzoni

toochainfile.cmake: rework the way Buildroot sets flags

2016-10-22T14:23:44+00:00

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) Cc: Max Filippov Cc: Thomas Petazzoni Signed-off-by: Samuel Martin Reviewed-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Thomas Petazzoni

toolchainfile.cmake: set per-config appended {C, CXX}FLAGS

2016-10-22T14:20:17+00:00

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) Cc: Maxime Hadjinlian Signed-off-by: Samuel Martin Reviewed-by: Arnout Vandecappelle (Essensium/Mind) [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

package/pkg-cmake.mk: move CMAKE_BUILD_TYPE definition into toolchainfile.cmake

2016-10-22T14:15:32+00:00

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) Cc: Maxime Hadjinlian Signed-off-by: Samuel Martin Reviewed-by: Arnout Vandecappelle (Essensium/Mind) [Thomas: reword description in the CHANGES file.] Signed-off-by: Thomas Petazzoni

support/misc/Vagrantfile: bump to ubuntu 16.04

2016-10-19T21:00:38+00:00

* Updating to ubuntu 16.04 * Fixing dependencies * Fixing locale complaints * Removing unused packages Signed-off-by: Angelo Compagnucci Reviewed-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Thomas Petazzoni

core: allow a br2-external tree to override a defconfig

2016-10-16T11:01:02+00:00

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" Cc: Thomas Petazzoni Cc: Arnout Vandecappelle Cc: Samuel Martin Cc: Romain Naour Cc: Julien CORJON Signed-off-by: Peter Korsgaard

Merge branch 'next'

2016-09-02T14:20:33+00:00

Quite some conflicts, so here goes .. Signed-off-by: Peter Korsgaard

Update for 2016.08

2016-09-01T09:30:19+00:00

Signed-off-by: Peter Korsgaard