Re: Bug#859177: meson is unuseable for package cross compilation
On Sat, Apr 01, 2017 at 02:01:07AM +0300, Jussi Pakkanen wrote:
> On Fri, Mar 31, 2017 at 4:31 PM, Helmut Grohne <helmut@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
Reply to: