Ubuntu started to flag which as deprecated and it
seems which is not really standard and may vary
across Distro.
Drop the use of which and use the standard 'command -v'
for this simple task.
Which is still present in the prereq if some package/script
still use which.
A utility script called command_all.sh is implemented that
will just mimic the output of which -a.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Speed goes from:
Executed in 178.08 secs fish external
usr time 20.16 mins 509.00 micros 20.16 mins
sys time 2.88 mins 39.00 micros 2.88 mins
To:
Executed in 175.90 secs fish external
usr time 20.19 mins 0.00 micros 20.19 mins
sys time 2.85 mins 497.00 micros 2.85 mins
Tested with "time make -j 12" on AMD Ryzen 3600
When building individual packages, the build time difference is often
significantly bigger than that.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Rosen Penev <rosenp@gmail.com>
ninja is faster at building cmake packages than make, and according to reports
also more reliable at handling parallel builds
This commit includes a patch that adds GNU make jobserver support, in order to
allow more precise control over the number of parallel tasks
Enable parallel build by default for packages using ninja
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Rosen Penev <rosenp@gmail.com>
This reverts commit c7aec47e5e3a3ff7b5fdaa11cd1e62cae6746acb.
The original commit replaces 'which' with 'command'. Sadly most of
them are not equivalent and for 'which -a', there is no easy
replacements that would not reimplement PATH parsing logic. Hence
revert. Keeping a dependency on which is absolutely fine.
Signed-off-by: Clemens Fruhwirth <clemens@endorphin.org>
`which` utility is not shipped by default for example on recent Arch
Linux and then any steps relying on its presence fails, like for example
following Python3 prereq build check:
$ python3 --version
Python 3.9.1
$ make
/bin/sh: line 1: which: command not found
/bin/sh: line 1: which: command not found
/bin/sh: line 1: which: command not found
...
Checking 'python3'... failed.
...
Fix this by switching to Bash builtin `command` which should provide
same functionality.
Fixes: FS#3525
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Commit f98878e4c17d ("cmake.mk: set C/CXX compiler for host builds as
well") has introduced regression as it didn't taken usage of ccache into
the account so fix it by handling ccache use cases as well.
In order to get this working we need to export HOSTCXX_NOCACHE in
rules.mk as well.
Fixes: f98878e4c17d ("cmake.mk: set C/CXX compiler for host builds as well")
Reported-by: Ansuel Smith <ansuelsmth@gmail.com>
Tested-by: Ansuel Smith <ansuelsmth@gmail.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Without this, cmake will use whatever CC/CXX is set to, which could be
clang. In that case, at least libjson-c/host will fail to compile.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
CMake provides a user package registry (stored in ~/.cmake/packages) and
a system package registry (not available on non-Windows platforms).
The "export(PACKAGE)" command may store information in the user package
registry, and the "find_package()" command may search both user and
system package registries for information.
This sets various variables to disable the use of these package
registries (both saving and retrieval of package information).
This also sets deprecated variables that perform similar functions, in
case external toolchains include older versions of CMake.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
Several CMake packages such as log4cplus and protobuf(-c) install to
lib64 instead of lib on some hosts. This completely breaks rpath linking.
Override it globally to avoid fixing each package individually.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Tested-by: Sebastian Kemper <sebastian_ml@gmx.net>
Sometimes, the CMakeLists.txt file is not in the root directory of a
repo. In those cases, the CMAKE_SOURCE_SUBDIR variable can be specified
to use CMakeLists.txt from a subdirectory instead.
Signed-off-by: Amol Bhave <ambhave@fb.com>
cmake checks the build system and its variables on its own to detect if
the makefiles need to be regenerated.
Unfortunately this can invalidate overrides passed in the
Build/Configure step. On non-Linux systems this breaks the build when
switching between targets of the same package architecture.
Fix this by forcibly disabling the build system check and relying on the
LEDE build system to take care of these things
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Using a single host package staging dir (and build dir) significantly speeds up
builds when multiple targets are built in succession, especially for large host
packages like NodeJS.
$(STAGING_DIR)/host is kept in addition to $(STAGING_DIR_HOSTPKG) in most
places; it is still used as destination for host files in Build/InstallDev.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Instead of using TARGET_CFLAGS and EXTRA_CFLAGS in cmake and scons
build use the TARGET_CXXFLAGS and EXTRA_CXXFLAGS like it is done for
normal make and configure. configure used TARGET_CXXFLAGS and
EXTRA_CFLAGS for the CXXFLAGS. The package-default.mk sets
"EXTRA_CXXFLAGS = $(EXTRA_CFLAGS)" so using EXTRA_CXXFLAGS flags should
be save.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Some packages need out of source tree building with cmake, for example
when building kernel modules.
See an example here:
https://sourceforge.net/p/accel-ppp/code/ci/master/tree/README
Signed-off-by: Luke McKee <hojuruku@gmail.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name> [cleanup, rework]
CMAKE_ASM_COMPILER is automatically set to CMAKE_C_COMPILER by CMake, but
CMAKE_C_COMPILER_ARG1 is lost. This causes assembly builds to fail when ccache
is enabled (for example the package fastd on x86).
Fix this by explicitly defining CMAKE_ASM_COMPILER and CMAKE_ASM_COMPILER_ARG1.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
SVN-Revision: 45119
Since GCC 4.7, GCC provides its own wrappers around ar, nm and ranlib, which
should be used for builds with link-time optimization. Since GCC 4.9, using them
actually necessary for LTO builds using convenience libraries to succeed.
There are some packages which try to automatically detect if gcc-{ar,nm,ranlib}
exist (one example is my package "fastd" in the package repository, which tries
to use LTO). This breaks because the OpenWrt build system explicitly sets the
binutils versions of these tools.
As it doesn't cause any issues to use gcc-{ar,nm,ranlib} instead of
{ar,nm,ranlib} even without LTO, this patch just makes OpenWrt use the
GCC-provided versions by default, which fixes the build of such packages with
GCC 4.9.
(I know that builds fail though when clang is used with -flto and
gcc-{ar,nm,ranlib}, but as all OpenWrt toolchains are based on GCC, this isn't
a real issue.)
Completely cleaning the tree (or at least `make clean toolchain/clean`) is
necessary to get a consistent state after the binutils plugins support patch and
this one (as trying to use gcc-{ar,nm,ranlib} with a binutils built without
plugin support will definitely lead to a build failure).
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
SVN-Revision: 43784
