Khem and Alexander, could you comment on which solution is preferable
from an SDK standpoint? Otherwise, could you nominate someone else to do
so in your place? :)
Here are the possible solutions proposed:
- Generate meson.cross toolchain file at SDK extraction time.
- Wrap meson with a shell script that dynamically generates a toolchain
file and then runs meson pointing to it.
- Change meson to support pulling in env vars in meson.cross, and use a
fixed meson.cross file that references the env vars.
On 01/09/2018 12:33 PM, Martin Kelly wrote:
On 01/09/2018 10:40 AM, Jussi Pakkanen wrote:
On Tue, Jan 9, 2018 at 8:20 PM, Martin Kelly <mke...@xevo.com> wrote:
Note the "native C compiler" line, which directly uses $CC.
I'm not sure if this is correct, but an easy way to fix the issue is to
ignore $CC for internal sanity checking when a cross file is
specified. In
that way, meson would probe the system and use the normal gcc for sanity
checking while still using the cross file for the actual build.
That breaks the whole reason the sanity check is there in the first
place. Its point is to test "is the native compiler the user has
specified working and capable of creating executables". If we change
it then that becomes "is the system default compiler (which we might
or might not use) working". We need to be able to support the case of
users defining both the cross compiler and the native compiler. So
something like this:
CC=/some/native/cc meson --cross-file=mycross.txt <other options>
Yeah, that makes sense. The issue here is that the OE SDK sets CC, CXX
etc to point to the cross compiler, not to the native compiler, so when
meson assumes it's native, things will break. I think we need a way to
specify both cross and host compilers separately from the env vars. For
example, if the binaries section were split in two: "host-binaries" and
"target-binaries", then in the cross-file case, meson could use
"host-binaries" instead of looking at CC and other vars.
Right now, the SDK contains fixed contents, and there is some
top-level logic
for rewriting a few paths to make everything relocatable. I don't
think OE
wants to inject a special-case one-time generation of the toolchain
file at SDK
extraction time, as it circumvents the normal build process,
Would it not be possible to generate the cross file when creating the
SDK contents originally? The only change it would need is the same
kind of path fixing. The setup does not really change.
I think it would be possible, but I'm guessing it would require some
special-casing that we may not want to do. Khem probably has a better
informed opinion on this than I.
Another approach would be to generate the toolchain file truly
"on-the-fly",
such that the meson command points to a script that first generates a
toolchain file based on the contents of CC, CXX, etc. and then runs
meson. I
think this is a bad idea because it is complex (will definitely surprise
people) and slow. It also breaks people in surprising ways when they
accidentally use a meson from outside the SDK due to the PATH setup.
This is, roughly, what Debian does currently.
That's too bad :).
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
