On 01/11/2018 11:33 AM, Martin Kelly wrote:
On 01/11/2018 11:26 AM, Khem Raj wrote:
On Thu, Jan 11, 2018 at 11:22 AM, Martin Kelly <mke...@xevo.com> wrote:
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.
We already have environment file, could it be used for meson as well
and needed
bits be generated during build time for SDK.
Yes, it is certainly technically possible. I'm wondering whether or not
that involves ugly special-casing, as I'm not familiar with the SDK
extraction code. If not, it's probably the best solution.
Specifically, looking at script meta/files/toolchain-shar-extract.sh, I
don't see a clean way to do something special for a single meson
package. There is no per-package hook or similar logic.
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
