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