Now that we require cmake-3.15, which is what upstream ninja requires,
we can drop the workarounds we carry to build with cmake-3.10.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Peter Seiderer <ps.report@gmx.net>
Cc: Yegor Yefremov <yegorslists@googlemail.com>
Cc: Philippe REYNES <philippe.reynes@softathome.com>
Reviewed-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
If the host cmake is 3.10, the configuration step produces
the following error:
CMake Error at CMakeLists.txt:87 (target_link_libraries):
Target "libninja" of type OBJECT_LIBRARY may not be linked into another
target. One may link only to STATIC or SHARED libraries, or to executables
with the ENABLE_EXPORTS property set.
This patch fixes CMakeLists.txt to use the object library as it was intended
in cmake 3.10.
Fixes:
https://bugs.busybox.net/show_bug.cgi?id=12546
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Tested-by: Damian Tometzki <dti@familie-tometzki.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes:
http://autobuild.buildroot.net/results/e5a02faa75345009e7cdcbf9d693199bee4741aa
-fdiagnostics-color was introduced in gcc 4.9 and the minimum supported version
that Buildroot supports is 4.8.
As this option only controls the colors of error messages, just drop it.
Signed-off-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The CMakeLists.txt file uses the CMP0091 which is an MSVC runtime
library flag abstraction macro.
Because we are not building ninja for Microsoft, it is safe to remove
this macro and set the minimum version to 3.10.
Fixes:
http://autobuild.buildroot.net/results/992b34c5625ec733d8dce678aa7a7540c4768ca1
Signed-off-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Ninja 1.10.0 now supports cmake as a build system. This change makes the make
file much more straightforward.
The host-python2 dependency is no longer needed as it is no longer
used during the build. We however need to keep install commands as
there is no installation step planned in CMakeLists.txt.
Signed-off-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
ninja depends on python3 specifically, but the configure.py file
simply uses "env python". Where no python is selected for the target
you simply won't get a python symlink in $(HOST_DIR)/usr/bin, so the
configure.py script fails to run since it can't find "python".
Notice that in order to reproduce the issue, you must not have
python2 installed on your host machine.
Signed-off-by: Avi Shukron <avraham.shukron@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
On Github, a large number of projects name their tag vXYZ (i.e v3.0,
v0.1, etc.). In some packages we do:
<pkg>_VERSION = v0.3
<pkg>_SITE = $(call github foo,bar,$(<pkg>_VERSION))
And in some other packages we do:
<pkg>_VERSION = 0.3
<pkg>_SITE = $(call github foo,bar,v$(<pkg>_VERSION))
I.e in one case we consider the version to be v0.3, in the other case
we consider 0.3 to be the version.
The problem with v0.3 is that when used in conjunction with
release-monitoring.org, it doesn't work very well, because
release-monitoring.org has the concept of "version prefix" and using
that they drop the "v" prefix for the version.
Therefore, a number of packages in Buildroot have a version that
doesn't match with release-monitoring.org because Buildroot has 'v0.3'
and release-monitoring.org has '0.3'.
Since really the version number of 0.3, is makes sense to update our
packages to drop this 'v'.
This commit only addresses the (common) case of github packages where
the prefix is simply 'v'. Other cases will be handled by separate
commits. Also, there are a few cases that couldn't be handled
mechanically that aren't covered by this commit.
Signed-off-by: Victor Huesca <victor.huesca@bootlin.com>
[Arnout: don't change flatbuffers, json-for-modern-cpp, libpagekite,
python-scapy3k, softether]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The current logic selects Python3 for the host only if Python3 is
selected for the target, otherwise it selects Python2.
As Meson, the only package infrastructure using ninja, needs Python 3,
it is desirable to also depend on Python 3 on the host for the ninja
host package.
Otherwise, if no Python interpreter is selected for the target, both
Python 2 and Python 3 are build for the host, which is time consuming
without any benefit.
For example when building libmpdclient (and all its target and host
dependencies) the actual elapsed time for is reduced from around 286s
to 207s as reported by `time -p make clean all`.
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since things are no longer installed in $(HOST_DIR)/usr, the callers
should also not refer to it.
This is a mechanical change with
git grep -l '$(HOST_DIR)/usr/bin' | xargs sed -i 's%$(HOST_DIR)/usr/bin%$(HOST_DIR)/bin%g'
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This new package provides the host variant of Ninja, a small build
system with a focus on speed.
[Peter: use install -D]
Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>