Commit Graph

114 Commits

Author SHA1 Message Date
Yann E. MORIN
7f654438c4 gitlab-ci: update the image version
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-08-15 09:47:00 +02:00
Thomas Petazzoni
90857e2dde support/misc/gitlab-ci.yml.in: use python3 for flake8
The pkg-stats script now uses Python3 only constructs (the "async"
keyword) and therefore fails to pass the Python2 flake8 test.

Let's use the Python3 flake8 instead.

Fixes:

  https://gitlab.com/buildroot.org/buildroot/-/jobs/681711009

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Titouan Christophe <titouan.christophe@railnova.eu>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-08-14 23:13:30 +02:00
Romain Naour
2ed3b0a586 gitlab-ci: check all defconfigs on every push
The defconfig check has been introduced by the previous
patch before the building each defconfig but those builds
are done every week or more.

Checking if a defconfig is valid can be done on every
push in the repository since it take few seconds.

This would allow to detect as soon as possible a problem
in a defconfig and eventually avoid breaking the build
while build testing all defconfig.

Introduce a new job template ".defconfig_check" in
gitlab-ci.yml.in and modify the generate-gitlab-ci-yml
to create a job for each defconfig to run the test.

Although, we could have used only one job to do all
tests, using one job per defconfig allow to identify
easily in gitlab which defconfig is falling.

Tested:
https://gitlab.com/kubu93/buildroot/pipelines/138331069
https://gitlab.com/kubu93/buildroot/pipelines/171223758

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-07-27 18:13:45 +02:00
Romain Naour
52b8ebc088 gitlab-ci: check generated config files
Use the script added by the previous patch to check
generated config files.

Tested on gitlab:
https://gitlab.com/kubu93/buildroot/pipelines/137597966

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-07-27 18:13:44 +02:00
Romain Naour
93a2870966 gitlab: generate the gitlab-ci configuration before each build
Since Gitlab 12.9, Gitlab allow to trigger child pipeline with generated configuration file.
See: https://gitlab.com/gitlab-org/gitlab/-/issues/35632

This allow us to stop updating the .gitlab-ci.yml file when a
new defconfig is added to Buildroot.

Remove check-gitlab-ci.yml job since it is now uneeded.
Remove .gitlab-ci.yml make target.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
[ann.morin.1998@free.fr: manual: no longer needed to update at all]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-07-27 13:45:52 +02:00
James Hilliard
5bb1827111 package/meson: bump to version 0.55.0
Drop fix rpath patch which is no longer needed.

Drop g-ir-scanner/g-ir-compiler override patch which is now upstream.

Rebase remaining patches.

Meson now requires single quotes for cross-compilation.conf, replace
double quotes with single quotes.

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-07-18 15:53:43 +02:00
Yaroslav Syrytsia
35c5cf56d2 Makefile: make-4.3 now longer un-escapes \# in macros
make-4.3 shipped with a backward incompatible change in how sharp signs
are handled in macros. Previously, up to make 4.2, the sharp sign would
always start a comment, unless backslash-escaped, even in a macro or a
fucntion call.

Now, the sharp sign is no longer starting a comment when it appears
inside such a macro or function call. This behaviour was supposed to be
in force since 3.81, but was not; 4.3 fixed the code to match the doc.

As such, use of external toolchains is broken, as we use the sharp sign
in the copy_toolchain_sysroot macro, in shell variable expansion to
strip off any leading /: ${target\#/}.

Fix that by applying the workaround suggested in the release annoucement
[0], by using a variable to hold a sharp sign.

[0] https://lists.gnu.org/archive/html/info-gnu/2020-01/msg00004.html

Signed-off-by: Yaroslav Syrytsia <me@ys.lc>
[yann.morin.1998@free.fr:
  - move the SHARP_SIGN definition out of Makefile and into support/
  - expand the commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-03-31 21:37:45 +02:00
Peter Korsgaard
5f5477b0ab Update for 2020.02
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-03-08 22:23:03 +01:00
Peter Korsgaard
836b84a774 Update for 2019.11
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-12-01 22:39:47 +01:00
Peter Korsgaard
1fcdfbfb8a Update for 2019.08
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-09-01 23:06:01 +02:00
Frank Vanbever
07f31ee263 support/cmake: Explicitly set CMAKE_SYSTEM
Some packages test for CMAKE_SYSTEM explicitly[1]

CMAKE_SYSTEM is comprised of CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_VERSION.
It defaults to CMAKE_SYSTEM_NAME if CMAKE_SYSTEM_VERSION is not set[2]

At the point CMAKE_SYSTEM_NAME is set to "Linux" CMAKE_SYSTEM is already
constructed. Setting it explicitly ensures that it is the correct value.

This is because we do set CMAKE_SYSTEM_NAME twice, in fact:

  - first in toolchainfile.cmake, so that we tell cmake to use the
    "Buildroot" platform,

  - second, in the Buildroot.cmake platform definition itself, so that
    we eventually behave like the Linux platform.

We also set CMAKE_SYSTEM_VERSION to 1, and so the real CMAKE_SYSTEM
value should be set to Linux-1 if we were to follow the documentation to
the letter.

However, for Linux, the version does not matter, and in some situations
may even be harmful (that was reported in one of the commits that
introduce Buildroot.cmake and toolchainfile.cmake).

[1] Fluidsynth 0cd44d00e1/CMakeLists.txt (L80)
[2] https://cmake.org/cmake/help/git-master/variable/CMAKE_SYSTEM.html#variable:CMAKE_SYSTEM

Signed-off-by: Frank Vanbever <frank.vanbever@mind.be>
Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
[Peter: update commit message with description from Yann]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-08-03 19:17:32 +02:00
Peter Korsgaard
8d4e26da08 Update for 2019.05
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-06-02 10:01:07 +02:00
Yann E. MORIN
9bde598ced infra/utils: add helper to generate comma-separated lists
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-04-15 23:24:13 +02:00
Peter Korsgaard
b9674056fb Update for 2019.02
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-03-04 22:49:56 +01:00
Yann E. MORIN
fc8a5f56b9 infra/pkg-cmake: use an obviously-invalid value for CMAKE_SYSTEM_VERSION
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-16 23:19:09 +01:00
Arnout Vandecappelle (Essensium/Mind)
36568732e4 package/pkg-cmake: add CMAKE_SYSTEM_VERSION to toolchainfile.cmake
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>
2019-01-12 16:06:51 +01:00
Peter Korsgaard
9089a9ff30 Update for 2018.11
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-12-01 23:06:49 +01:00
Peter Korsgaard
721e4cbb52 Merge branch 'next'
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-09-07 13:13:17 +02:00
Peter Korsgaard
339d550e92 Update for 2018.08
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-09-06 22:11:06 +02:00
Angelo Compagnucci
8511a66fc1 support/misc: updating Vagrantfile to ubuntu 18.04
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-08-13 11:45:48 +02:00
Damien Thébault
d8c0faa980 support/misc/toolchainfile.cmake.in: use TARGET_LDFLAGS for shared and 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-07-19 09:33:37 +02:00
Peter Korsgaard
f3d114a1ef Update for 2018.05
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-06-01 22:22:57 +02:00
Peter Korsgaard
8a94ff12d2 Update for 2018.02
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-03-04 22:28:34 +01:00
Peter Korsgaard
9dd76697cc Update for 2017.11
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-11-30 22:35:17 +01:00
Peter Korsgaard
8ce27bb9fe Update for 2017.08
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-09-02 01:17:43 +02:00
Wolfgang Grandegger
f45f0c2d40 support/scripts: relocate-sdk.sh now uses a normal pipe to find strings
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-20 22:29:12 +02:00
Wolfgang Grandegger
9c542ba06d support/scripts: relocate-sdk.sh now creates sdk-location in share/buildroot
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-20 15:47:41 +02:00
Arnout Vandecappelle
58fd643d52 pkg-cmake: programs are now installed in $(HOST_DIR)/bin
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-05 11:50:21 +02:00
Arnout Vandecappelle
787a45a71a pkg-cmake: move configuration files out of $(HOST_DIR)/usr
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-05 11:50:14 +02:00
Wolfgang Grandegger
8ec29ef3e4 support/scripts: add relocate-sdk.sh script for SDK relocation
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-07-04 17:59:37 +02:00
Rahul Bedarkar
52c724d3d4 support/misc/target-dir-warning.txt: fix typo
s/owernship/ownership/

Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-06-14 21:14:59 +02:00
Peter Korsgaard
dd2020aadf Update for 2017.05
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-05-31 23:55:40 +02:00
Yann E. MORIN
894ad2b094 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-05 21:34:49 +01:00
Yann E. MORIN
56aaef5533 support/cmake: impersonate a Linux system even more
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-02 22:09:34 +01:00
Yann E. MORIN
c69b14fe2f 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-03-01 21:56:24 +01:00
Peter Korsgaard
083c0735e9 Update for 2017.02
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-02-28 22:00:23 +01:00
Angelo Compagnucci
410082e1d9 support/misc/Vagrantfile: reorganize provisioning
* 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 

Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-26 21:15:13 +01:00
Peter Korsgaard
a3e4b0fb53 Update for 2016.11.2
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-01-25 09:55:14 +01:00
Peter Korsgaard
67f23a77c2 Update for 2016.11.1
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-12-29 22:24:06 +01:00
Peter Korsgaard
a7eb052ff8 Update for 2016.11
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-11-30 23:16:22 +01:00
Stefan Nickl
0fb2263d29 pkg-cmake: Change -DNEBUG to -DNDEBUG
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-11-06 22:30:40 +01:00
Thomas Petazzoni
7d2407b3e7 toolchainfile.cmake: fix description of CMAKE_Fortran_FLAGS_{DEBUG,RELEASE}
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-22 16:44:06 +02:00
Samuel Martin
10a6756fa1 toochainfile.cmake: rework the way Buildroot sets flags
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  [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-22 16:23:44 +02:00
Samuel Martin
12494ef48f 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-22 16:20:17 +02:00
Samuel Martin
a471150a7b package/pkg-cmake.mk: move CMAKE_BUILD_TYPE definition into toolchainfile.cmake
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-22 16:15:32 +02:00
Angelo Compagnucci
6294204686 support/misc/Vagrantfile: bump to ubuntu 16.04
* 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-19 23:00:38 +02:00
Yann E. MORIN
339e1c9500 core: allow a br2-external tree to override a defconfig
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-10-16 13:01:02 +02:00
Peter Korsgaard
7353967690 Merge branch 'next'
Quite some conflicts, so here goes ..

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-09-02 16:20:33 +02:00
Peter Korsgaard
78e9914628 Update for 2016.08
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-09-01 11:30:19 +02:00
Yann E. MORIN
242e0087e5 core: move pkg-utils.mk to support/
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-27 16:03:35 +02:00
Samuel Martin
e8c3755676 pkg-cmake.mk: set CMAKE_SYSROOT variable in toolchainfile.cmake
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-08-18 22:27:19 +02:00
Samuel Martin
019ba1dc52 pkg-cmake.mk: export the fortran compiler path in the CMake toolchain file
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-07-03 16:58:11 +02:00
Peter Korsgaard
aa6fd11fee Update for 2016.05
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-05-31 23:52:36 +02:00
Peter Korsgaard
aaf6c28a5c Update for 2016.02
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-01 21:47:30 +01:00
Angelo Compagnucci
778026b94d support/misc: Adding Vagrant file for provisioning
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>
2016-02-04 17:25:54 +01:00
Arnout Vandecappelle
e31ad0e809 package-cmake: remove now-redundant target ccache support
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-10-04 18:22:20 +02:00
Samuel Martin
252e57cf16 toolchainfile.cmake: only search the sysroot for CMake module
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>
2015-03-16 22:16:45 +01:00
Volker Krause
c1e41153e6 pkg-cmake.mk: Set CMAKE_SYSTEM_PROCESSOR.
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-12-09 23:00:12 +01:00
Samuel Martin
47544e43a5 toolchainfile.cmake.in: do not force the CMAKE_{C, CXX}_FLAGS to the cache
Fix  [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-28 20:57:26 +02:00
Samuel Martin
474a0e113e toolchainfile.cmake.in: set linker flags
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-09-28 20:52:52 +02:00
Samuel Martin
c8f2d248f6 pkg-cmake.mk: enable ccache for cmake packages
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>
2014-06-01 22:16:24 +02:00
Samuel Martin
9033d90118 pkg-cmake.mk: do not hardcode absolute path in toolchainfile.cmake
The patch allows sharing or moving the toolchains.

This is a step toward making the toolchain/sdk relocatable.

Closes 

[Peter: reword comment as suggested by Thomas]
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Cc: Uwe Strempel <u.strempel@googlemail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-06-01 22:15:43 +02:00
Samuel Martin
85fea5d953 pkg-cmake.mk: refactor the toolchainfile.cmake generation
This patch introduces a toolchainfile.cmake.in template which is filled
by Buildroot.

Using a toolchainfile.cmake.in template file allows to avoid overloading
quoting and/or escaping and it becomes much more similar to the
resulting file.

This patch also cleans up the quoting style.

[Peter: drop stdin redirect as suggested by Thomas]
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-06-01 22:11:38 +02:00
Thomas Petazzoni
9226a9907c Warn the user about the usage of output/target as the root filesystem
A very common mistake done by our users is that they use
output/target/ directory as their root filesystem. Even though this is
loudly documented in our Buildroot manual, people don't read
documentation, so it is not sufficient.

This patch adds a text file named
output/target/THIS_IS_NOT_YOUR_ROOT_FILESYSTEM which explains why
output/target isn't appropriate to use as the root filesystem. The
process is:

 * At the beginning of the build, right after the skeleton has been
   copied, support/misc/target-dir-warning.txt is copied to
   output/target/THIS_IS_NOT_YOUR_ROOT_FILESYSTEM

 * In the filesystem images creation code, this file is removed before
   launching fakeroot, and restored right after that, so that this
   file is not present in the generated root filesystem images.

Note that the file has not been added to the default skeleton for two
reasons:

 * It would have annoying to have in our source tree a file named in
   capital letters inside system/skeleton/

 * The proposed way works even if the user uses a custom skeleton.

[Peter: fixed typo]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Juha Lumme <juha.lumme@gmail.com>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-11-17 17:12:49 +01:00