Hi Simon, Thanks for looking into this issue!
On Wed, Oct 11, 2017 at 09:37:42AM +0100, Simon McVittie wrote: > On Wed, 13 Sep 2017 at 21:01:43 +0200, Helmut Grohne wrote: > > debarch cpu cpu_family > > armel arm armv7l > > Is this a typo, or is this really what Meson does? I would expect > cpu=armv7hl and cpu_family=arm. Thanks for correcting me. > Is cpu_family intended to describe a CPU family, or an ABI? Some CPU > families have more than one incompatible ABI: It's not clear to me what the intention is. My experience matches yours though: cpu and cpu_family are incapable of differentiating ABIs. > On Thu, 14 Sep 2017 at 00:26:04 +0300, Jussi Pakkanen wrote: > > When compiling with Meson, CC and CXX must point to the native > > compilers, not to cross compilers. > > That's CC_FOR_BUILD in config.guess and many Autotools projects (also > CPP_FOR_BUILD for cpp, and > https://www.gnu.org/software/autoconf-archive/ax_prog_cc_for_build.html > doesn't define CXX_FOR_BUILD but it would be a logical extension). > Perhaps Meson should look at those variables first, when building things > for the build system? (In GNU terminology: build is the machine where > Meson runs, host is the machine where the result of compilation will be > run.) It probably should, but performing that change would be an API break for meson. Furthermore, you are not supposed to rely on environment variables for cross compilation: You're supposed to write all of that to your "crossfile". I don't agree with that approach, but it seems the way taken by meson. > If I wanted to cross-compile with Meson using a non-standard > cross-compiler, for instance running aarch64-linux-gnu-clang instead of > aarch64-linux-gnu-gcc on my x86_64 system, is there an environment variable > that can be set to achieve that, or do I have to generate a non-standard > cross-compilation definition file and use that? Your interface always is the "crossfile". For Debian, we're going to generate those with debcrossgen. Presently, it does not have an interface to influence its output in the way you would like. Yet my vision for debcrossgen is that it should become an adapter between the autotools interface (tell a gnu-triplet and pass variables such as CC) and meson. Potentially, it can become distribution agnostic at some point. It may have to use config.guess eventually. Let's see where this is going. > On Thu, 14 Sep 2017 at 00:26:04 +0300, Jussi Pakkanen wrote: > > Yes, we do indeed to some canonicalization here. > > Are you deliberately inventing a new vocabulary of CPU types? I cannot tell about the "deliberately" part, but otherwise "yes". > If possible (and if it's not too late!) it would be great if this > vocabulary reused some existing one (for example GNU CPU types, which > in fact debcrossgen assumes are the vocabulary in use), or at worst, > was defined to be the same as some existing vocabulary with documented > exceptions (like x86 for the i?86 family). Again, doing so would constitute an API break on behalf of meson and it would break a number of meson files. And yet, I believe that doing exactly that would avoid a lot of pain down the road. Unfortunately, it'd also means gaining a dependency on autotools-dev for using its config.guess. I doubt that Jussi will add that dependency. > The GNU tuples (like i386-linux-gnu) seem to be a de facto standard for > cross-compilation: projects that use Make but not Autotools often run > things like "$(CROSS_COMPILE)cc" and expect you to put a GNU tuple + > "-" in CROSS_COMPILE if you are cross-compiling. It works beyond cc. binutils, pkg-config, a number of foo-config scripts and more use that convention. I agree that this is the de facto standard. Meson is non-standard here. Then again, this is a pretty unix-ish standard and meson tries to cover more. > * Python platform.machine() (no documentation of the vocabulary that > I know of; it seems to be uname machine on Unix, but x86 or AMD64 on > Windows, so in practice the vocabulary varies arbitrarily per-OS) This one is exactly the one meson uses. Do note that config.guess also uses uname (unless given a triplet). So it'll always boil down to uname at some level. The good thing about config.guess is that it is very widely adopted. Meson also normalizes platform.machine() in a different way. It thus creates a new vocabulary. > CMake has some sort of ad-hoc vocabulary of CPU types but as far as I'm > aware, doesn't document what it expects to see there, or even whether > it can vary between OSs. It would be great if Meson avoided making the > same mistake. Yes, this is annoying. The only reasonable way to work with CMake is relying on the compiler to do the right thing. > If you're OK with assuming that the Python that is running Meson was > built for the desired architecture (which seems reasonable on Unix, > although possibly not on Windows) then > sysconfig.get_config_var('HOST_GNU_TYPE') can tell you that. Meson is presently working with that assumption. Switching from platform.machine to sysconfig.get_config_var would be a change in vocabulary, but not in assumptions. > > > mips mips64 mips64 > > > mipsel mips64 mips64 > > > > These should be plain mips (assuming that this is mips32 userland > > running on top of a 64 bit kernel). Probably. I listed them here to demonstrate that mesons's present vocabulary is broken. So maybe we should acknowledging that the vocabulary is broken and thus breaking it is a reasonable approach anyway? > 32-bit ARM can also run on an aarch64 kernel, and 31-bit S390 can run > on a 64-bit S390x kernel, so uses of that approach will tend to > proliferate. Detecting the build architecture's bit width from uname -m > just doesn't work very well, unfortunately: uname -m is a fact about > the kernel rather than a fact about the user-space OS. Exactly. I've been asked what build system to use a number of times now. Presently, I tell people to avoid meson, because it is badly integrated in Debian (debcrossgen is still broken), because it's architecture vocabulary is broken and because override mechanisms (e.g. different CC) are annoying to use (edit the crossfile). That's sad, because there is so much potential in meson. Please Jussi, make those reasons go away and let me tell people to use meson. Helmut
