[OE-core] Issues with meson in SDK with cross-file

[Nirbheek Chauhan]

(re-sending because the previous one was automatically rejected
because I wasn't subscribed)

On Tue, Jan 9, 2018 at 5:21 AM, Martin Kelly <mkelly at xevo.com> wrote:
> [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!).

Great to hear that! Thanks for your work, Alexander :)

[snip]
> - 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:
>

It does support that as of 0.43:

http://mesonbuild.com/Release-notes-for-0-43-0.html#can-override-executables-in-the-cross-file

I believe this should solve your problems with cross-tools at least.
Note that this also works for pkg-config, g-ir-compiler, g-ir-scanner,
etc.

> $ 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).

Out of interest, why is that not good? That is precisely what Gentoo
does and it has to solve the same problems here that Yocto is facing.

> 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:
>

Meson tries to reduce reliance on env vars as much as possible; the
cross file is meant to be a standalone object. I would be happier if
we could find a way to make things work for Yocto within that
framework to keep complexity down. If that's not possible, we can look
at changing things around.

> - 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.
>

Would it be possible to tell Yocto to not set those vars when building
a recipe that uses meson?

> - Add the ability to reference env vars in cross files to support
> relocatable toolchains.
>

That's one idea, but it adds a certain amount of complexity. Let's
keep that on the table for now.

Cheers,
Nirbheek