Follow the changes in Clang search paths and specify sysroot via the
TOOLCHAIN_OPTIONS, otherwise clang will fail to find system headers when
executed by bindgen.
For SDK packages TOOLCHAIN_OPTIONS don't contain full sysroot path, so
specify the correct directory explicitly.
(From OE-Core rev: a647a0ff4c4eb7a7c1f6ec84a574f7d7796b6178)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to properly generate Rust bindings for the target systems, we
need to pass '-taget foo-linux-gnueabi' flags and a correct include
target include path (${STAGING_INCDIR}) to the bindgen. Add those
flags to the generated meson target file.
(From OE-Core rev: 40008d55c01681c60088e5b7defb0b8513a4ed1c)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The feature is available since meson 0.60.0. You can specify
comma-separated list of install tags (not targets).
(From OE-Core rev: a61ec67cb6f240c7593c9dd1b9a1ef5fff87c855)
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
nativesdk builds are cross-builds like target ones, and
so meson expectations regarding ability to run binaries are the same:
either provide the wrapper, or disable the build time options that
need executing target binaries during build time (if such options
are made available by upstream).
(From OE-Core rev: f210fc1d3db2e71f484bddc0b23ab252c36f4062)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit fc8e5d7c13.
We need to use the absolute path to the compiler so that the VSCode
configuration generated by devtool ide-sdk could lint meson projects.
A feature was just added to vscode-cpptools to support conveying the
compilerPath in addition to the compile_commands.json. The next
commits adds the necessary configuration. We can revert this one and
keep the meson paths as they were.
(From OE-Core rev: 9c2faa835bd7af3e6f6bd7cc08495bd4b3ca9d0b)
Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Among the files generated by meson is compile_commands.json. It is not
used by bitbake during the build. However, if the devtool workspace is
opened inside an IDE, that IDE can use compile_commands.json to
configure linting and code completion. This is notably relied on by the
new devtool ide-sdk command.
The problem is that the IDE using compile_commands.json does not know
the $PATH set-up by bitbake, so it won't find the compiler. This results
in linting errors, like missing headers. We can fix this by expliciting
the absolute compiler paths in meson.cross.
The compile_commands.json specification expressly states:
"All paths specified in the command or file fields must be either
absolute or relative to this directory."
Link: https://clang.llvm.org/docs/JSONCompilationDatabase.html
An alternative way to implement this is to directly change CXX inside
bitbake.conf to make all recipes use absolute compiler paths.Since this
would affect all recipes, so I would like to have the maintainers'
opinion on this. It could make sense to use absolute compiler paths for
all toolchain binaries, we already do so for the sysroot
TOOLCHAIN_OPTIONS.
Discussions have been opened with meson/ninja maintainers to implement
this at their level:
- https://github.com/ninja-build/ninja/issues/2383
- https://github.com/mesonbuild/meson/issues/12834
These tools have even less information on the environment so it makes
sense for Yocto to provide the absolute paths.
(From OE-Core rev: b4e00248049c2627b05eafa9313a48cf253623fa)
Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When cross compiling we have a sysroot, so by telling Meson where it is
explicitly it can do the right thing.
Currently this means it just sets PKG_CONFIG_SYSROOT_DIR to the value
that we already set it to, but in the future this can be used to stop
Meson looking directly in /usr when it shouldn't.
(From OE-Core rev: 62d4fd215a0886056d64e926f722cd07e9986118)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We had to export TMPDIR because Meson was writing temporary files into
/tmp and then trying to run them, but some systems had /tmp mounted
noexec.
This is now solved upstream as of meson commit 1e182b5 (which was part of
Meson 0.52.0), and these temporary files are written to the build tree
instead.
(From OE-Core rev: 1809d20f92dc0e4eff19cf081ca78a9f30deb611)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Follow the example of rust and cargo classes and pass RUST_HOST_SYS and
RUST_BUILD_SYS to rustc's --target argument instead of bare HOST_SYS and
BUILD_SYS.
(From OE-Core rev: 1471c6c076f544ccd6f0722c82878311199881a7)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add OBJCOPY and EXEWRAPPER_ENABLED, remove LD as it isn't used anymore.
(From OE-Core rev: 920f6cb25c06fde679f641a076a8e17dc36a828e)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a variable to control what target gets built in do_compile. By
default this value is unset so meson builds the default target, but by
setting MESON_TARGET a specific target can be built.
(From OE-Core rev: bd82ccc819ec90af08216fe780af6a66f1d347b3)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Default search in meson would grok /usr/bin for llvm-config and if found
will use it, which might add wrong paths into cflags/ldflags, since we
depend on llvm-native when building gallium support ( thats when
llvm-config is effective), its better to point llvm-config into native
sysroot so it can add correct paths into compiler/linker cmdline
(From OE-Core rev: cc73360b9728812ed6123e30559b77d8e89cc21c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is no longer need to be specific: none of the recipes
using this variable in core need to know the particular version
of llvm exactly when using the default one set via PREFERRED_VERSION
from LLVMVERSION.
This as well enables automated version updates of llvm
for minor releases.
(From OE-Core rev: f0ab1736438f6f23603e3694dc2f0b724b103722)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On install, Meson will rebuild targets which don't define their
dependencies, as it can't know if they need to be rebuilt or not.
This includes gtk-doc, which can be slow to run. As we control the
execution of meson we know that a rebuild isn't required, so we can pass
--no-rebuild and speed up the install task.
(From OE-Core rev: da7e8bbb75bfb1a1c820b310196e510c05fc67c7)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Invoking meson with just paths is a deprecated use of the binary and
causes warnings, so call 'meson setup' explicitly.
Whilst doing this cleanup, we can also call 'meson compile' and 'meson
install' instead of ninja.
(From OE-Core rev: b248cb1ada04f57a5c4590c7e5efa04f68bc8843)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move classes to classes-global or classes-recipe as appropriate to take
advantage of new bitbake functionality to check class scope/usage.
(From OE-Core rev: f5c128008365e141082c129417eb72d2751e8045)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
