On Wed, 11 Oct 2017 at 19:23:09 +0200, Helmut Grohne wrote: > On Wed, Oct 11, 2017 at 09:37:42AM +0100, Simon McVittie wrote: > > 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.
It turns out http://mesonbuild.com/Reference-tables.html documents the vocabulary of CPU types, so that's already doing a lot better than CMake... | Value | Comment |----------|--------------------- | x86 | 32 bit x86 processor | x86_64 | 64 bit x86 processor | arm | 32 bit ARM processor | | Any cpu family not listed in the above list is not guaranteed to remain | stable in future releases. So if the vocabulary changed to this, for instance: x86 32-bit x86 (i386..i686) arm 32-bit ARM anything else (including x86_64) same meaning as in Autotools that wouldn't currently be considered a break. > Unfortunately, it'd also means gaining a dependency on > autotools-dev for using its config.guess. Not necessarily; if there was a policy of, for instance, "for architectures that have actual users and are not i?86, detecting a CPU type that differs from the Autotools vocabulary is a bug, patches welcome" then that would be equally useful for Meson users. In practice, entirely new architectures like aarch64, nios2, or1k get the same value for Linux uname -m as in the GNU vocabulary (because that's by far the easiest implementation for config.guess); so the only difference would be what happens to architectures with a historical special case (like the x86, mips and powerpc families), and that's finite. > > 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. I'm not sure it is the same thing. If you run i386 binaries (and in particular Python) on an amd64 kernel, platform.machine() tells you about the kernel but sysconfig tells you about the Python binary: root@host:~# uname -a Linux host 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64 GNU/Linux root@host:~# dpkg-query -W python3 python3:i386 3.5.3-1 root@host:~# python3 -c 'import platform; print(platform.machine())' x86_64 root@host:~# python3 -c 'import sysconfig; print(sysconfig.get_config_var("HOST_GNU_TYPE"))' i686-pc-linux-gnu > Please make those reasons go away and let me tell people to use meson. That's what I'm hoping for too :-) Regards, smcv
