[Jussi Pakkanen, Nirbheek Chauhan, I know you may not be on the list; I
added you to get Yocto/OE and meson upstream all on the same thread to
discuss integrating the two]
Hi all,
Recently, we got meson added to OE-core as part of Yocto (thanks
Alexander Kanavin!). That said, it doesn't yet work with the Yocto SDK.
I tried adding SDK support to the existing meson recipe (BBCLASSEXTEND =
"nativesdk") and hit some issues that require some thought.
I wanted to get OE and meson upstream on one thread to discuss the
issues and come up with clean solutions for solving them.
The issues I'm seeing arise because meson and OE appear to have
differing views of how a cross-compile should look. Specifically:
- meson assumes that CC, CXX, CFLAGS, and other vars point to native
tools. However, in an OE SDK, they point to cross-tools. Thus meson
fails under the SDK when because it tries to use the cross-tools for
native tasks (I get the error "nm does not work" because meson tried to
use the cross-nm for symbol extraction).
- The cross-file does not support relocatable cross-tools. This is an
issue because OE SDKs are self-extracting shell scripts that can be
installed anywhere on a machine. Once installed, they populate the env
with --sysroot= and other flags pointing into the installed SDK
location. For example, if I install an ARM SDK into /tmp/sdk, I would
get something like this:
$ echo $CC
arm-poky-linux-gnueabi-gcc -march=armv7ve -marm -mfpu=neon-vfpv4
-mfloat-abi=hard -mcpu=cortex-a7
--sysroot=/tmp/sdk/sysroots/cortexa7hf-neon-vfpv4-poky-linux-gnueabi
If we want to setup a cross-file to use these arguments, we would have
to generate the cross-file on-the-fly (not good). The way the cmake
toolchain file solves this is by encoding env vars into the toolchain
file, which then picks up the dynamically set CC, CXX, CFLAGS that point
to the cross-tools:
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake
I'm not a meson expert, so I don't know if these are the right
solutions, but here are my proposed solutions just so I can get the
discussion started:
- When --cross-file is specified, make meson not assume that env vars
like CC and CXX and similar point to native tools. Instead, just ignore
them and look for native tools in the normal way that meson does when
these vars are unspecified. We still may wan to inject CFLAGS, LDFLAGS,
etc into the build because people may mess with them interactively
during development.
- Add the ability to reference env vars in cross files to support
relocatable toolchains.
This would basically make meson behave the way cmake does today.
Of course, others may have better ideas; I welcome thoughts.
Thanks,
Martin
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
