On Sat, Apr 01, 2017 at 02:01:07AM +0300, Jussi Pakkanen wrote: > On Fri, Mar 31, 2017 at 4:31 PM, Helmut Grohne <hel...@subdivi.de> wrote: > > > The `makefile` buildsystem in `debhelper` even just sets > > `CC=${DEB_HOST_GNU_TYPE}-gcc`. The convention is: prefix host tools with > > the host's GNU triplet. > > This does not work. For Meson, CC always means "the native compiler". > This is just a matter of unsetting that var (or making it point to > /usr/bin/cc, whichever is simpler).
It was just meant as an example for how the compiler name is being constructed. The way of telling meson can certainly be different. > > I agree that shipping this as a Debian-ism may prove easier for > > development of the thing. As you are the maintainer and agree with that > > idea, it sounds like a plan. Still, I would like to avoid using any > > Debianisms in the implementation (as CMake still does in some parts) to > > ease upstreaming down the road. > > AFAICR CMake has a similar concept of a toolchain file for cross > compilations. How are they dealt with in Debian? CMake does not mandate the use of a toolchain file. Instead it mixes the toolchain definitions into its variable scope and thus they can be changed like any other user configurable option with a suitable `-Dfoo=bar` flag. Then `debhelper` sets[1] lots of them. > In Meson we avoid making absolutely everything configurable in a > gazillion different ways. It just leads to frustration. We prefer > explicit data in (preferably only one) place and for cross compilation > that is the cross file. Having one plain text file with all the > information makes e.g. debugging a lot simpler. That makes sense to me. Indeed that way simplifies approaching meson. > Those numbers are a bit off. Information about the build machine is > not stored in the cross file, it is detected at runtime, identically > to how native building would work. Thus cross compiling for 36 > architectures would require 36 files or 72 if accounting for cases > where target is specified but host is not. You'd only need to go to > 36*36 = 1296 files if you want to support cross compiling cross > compilers on all possible combinations. The difficulty here is deciding in advance which combinations are relevant. However you decide, tomorrow a new arch will come along and you'll have to add it posing a constant stream of maintenance. I've seen that with `libgpg-error`, `guile-2.0`, `jemalloc`, etc. Trust me: It's a pain (at least for me having to report all those bugs). If that 36 were a mostly static number, that'd draw a different picture. > That being said generating them live is probably a good approach, it > seems to be mostly a question of mangling the output of > dpkg-architecture. Yes. That's also essentially how the command line parameters for CMake are constructed[1]. > That is old code that is not used much any more. Nowadays we don't do > library lookups based on file paths but instead by asking the compiler > (i.e. we know library 'foo' is available if compilation with the > desired compiler when using '-lfoo' passes. > > Still, that should probably be fixed at some point. Glad to hear that. As a first step, maybe update the docstrings telling that these shouldn't be used pointing to the alternatives? I have the feeling that meson gets quite a few things "right" (from a cross build maintainer's view). Too bad we're late for stretch. I was almost considering switching some CMake projects to meson due to the much better handling of build/host/target. Helmut [1] http://sources.debian.net/src/debhelper/10.2.5/Debian/Debhelper/Buildsystem/cmake.pm/#L59