(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 <mke...@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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core