21/06/2022 13:05, Stanisław Kardach: > On Tue, Jun 21, 2022 at 12:22 PM Thomas Monjalon <tho...@monjalon.net> wrote: > > > > 21/06/2022 11:49, Bruce Richardson: > > > On Tue, Jun 21, 2022 at 11:42:55AM +0200, Stanisław Kardach wrote: > > > > On Tue, Jun 21, 2022 at 11:39 AM Bruce Richardson > > > > <bruce.richard...@intel.com> wrote: > > > > > <snip> > > > > > Generally the "cpp" binary is not the c-plus-plus one, but the C > > > > > preprocessor one. Perhaps the original files are incorrect here, and > > > > > should > > > > > all refer to g++. > > > > > > > > > > /Bruce > > > > > > > > > That does make sense. I'll submit a separate patchset fixing all > > > > occurrences (of which there are many). > > > > > > > > > > As a more general note for future consideration, I notice that in meson > > > 0.56 the cross-file support has been enhanced with the ability to use > > > constants and therefore separate out prefixes.[1] > > > > > > When we get to the point where we feel we can mandate meson 0.56 upwards > > > for cross compilation, we should look to leverage this. It should even > > > allow other scripts such as test-meson-builds to auto-generate the > > > constant > > > paths to the binaries on the fly, effectively allowing the use of > > > environment variables for these - something previously requested by > > > Thomas. > > > > That would be great. > > Cross compilation prefix is such a basic thing, we should handle it > > properly. > Please correct me if I'm wrong but it seems that meson's approach to > cross-compiling is to package all settings into cross-files. Probably > under assumption that a repeatable compilation is more important than > flexibility and that there are compiler-specific knobs that need/can > to be tuned. Therefore reading CROSS_COMPILE/prefix from environment > is intentionally made hard.
If it is made intentionally hard, it is just a wrong design. A toolchain prefix is just a name. We can have 2 toolchains compiled with the same name and different behaviours. And we can have 2 similar toolchains with a different name. > So should the direction be environment or rather separating > cross-files into arch-part and toolchain-parts and letting user create > his own toolchain part while maintaining a matrix of supported > combinations for CI? I'm not advocating either, just want to wrap my > head around it. We should be able to use a toolchain compiled anywhere without modifying the cross files, just because a "-gnu-" is missing or any other irrelevant detail.
