buildroot/support/misc, branch 2017.05

Update for 2017.05

2017-05-31T21:55:40+00:00

Signed-off-by: Peter Korsgaard

core/pkg-cmake: better way to pass our CMAKE_MODULE_PATH

2017-03-05T20:34:49+00:00

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" Cc: Samuel Martin Cc: Jörg Krause Cc: Ben Boeckel Cc: Baruch Siach Cc: Vicente Olivert Riera Cc: Thomas Petazzoni Cc: Arnout Vandecappelle Cc: Peter Korsgaard Signed-off-by: Thomas Petazzoni

support/cmake: impersonate a Linux system even more

2017-03-02T21:09:34+00:00

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 Reported-by: Baruch Siach Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Cc: Baruch Siach Cc: Ben Boeckel Cc: Jörg Krause Cc: Vicente Olivert Riera Cc: Samuel Martin Signed-off-by: Thomas Petazzoni

core/pkg-cmake: provide our own platform description

2017-03-01T20:56:24+00:00

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" Cc: Jörg Krause Cc: Ben Boeckel Cc: Baruch Siach Cc: Samuel Martin Cc: Vicente Olivert Riera Cc: Thomas Petazzoni Cc: Peter Korsgaard Reviewed-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Thomas Petazzoni

Update for 2017.02

2017-02-28T21:00:23+00:00

Signed-off-by: Peter Korsgaard

support/misc/Vagrantfile: reorganize provisioning

2017-02-26T20:15:13+00:00

* 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 Signed-off-by: Thomas Petazzoni

Update for 2016.11.2

2017-01-25T08:55:14+00:00

Signed-off-by: Peter Korsgaard

Update for 2016.11.1

2016-12-29T21:24:06+00:00

Signed-off-by: Peter Korsgaard

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