Conditional test for detecting cross-compilation

[michaelpj]

Describe the feature request
At the moment, anything that requires running code on the build platform tends to be broken (or a pain to make work) when doing cross-compilation, e.g.

• Compiler plugins
• Custom setups that call out to external binaries
• TH that calls out to external binaries

It would be nice to be able to state that such packages won't work when cross-compiling, much as it can be useful to say that some package just won't work on, say, Windows.

i.e. I want to write

if cross
  buildable: False

Possibly it would be better to instead have tests like host-os and build-os rather than just os, but then we would also need to be able to say

if (host-os != build-os)

or something. Not sure if that fits into cabal's conditional model.

Additional context

We have a lot of packages, and we want to cross-compile most of them. At the moment what we do is try to cross-compile all of them, with exceptions. However, we can generally be smart enough to avoid things that are not buildable (I think cabal does not plan them, which is better than e.g. getting a planning failure). But we can't state the constraint that some packages don't build when cross-compiling, so we have to have manual exceptions for them.

[Mikolaj]

@mpickering proposes, among other things, to make it more fine-grained.

Would the more-fine grained alternative be if plugins_supported and if TH_supported or are there many more possible breakages stemming from cross-compilation?

[michaelpj]

Cabal doesn't know about plugins at all - that's part of the problem. So it would be weird for cabal to say that plugins aren't supported when in fact it doesn't really support them at all. It would be nice to fix that, see #7901 for some ideas. But it's a whole big thing!

TH is supported. It's just... weird when cross-compiling because you're running via iserv which is pretending to be on the host. But you also don't want to condition on using iserv, because you can use the external interpreter when not cross-compiling and it's fine.

I sympathise with the desire to state the actual problem, but IME there tend to be lots of weird issues when cross-compiling from all kinds of sources. System dependencies of various kinds can be broken. In practice, "it's broken because cross" seems to be common, and while there are sub-categories, I do think it it's useful to talk about as just a case where weird stuff happens.

[michaelpj]

Ah yes, more stuff that doesn't really work:

• Anything that depends on ghc
• doctest

[Mikolaj]

Let me copy a snippet by @mpickering

You can easily detect if the configured compiler is a cross compiler
by looking at ghc --info
I am not sure it's a great idea though
because there's some features which cross compilers could support but just don't at the moment
it would be better to guard via specific flags

where Matthew points out that how broken cabal is with cross-compilers is going to change (for the better, I hope). What's the worst that can happen? E.g., somebody marks a section of the cabal file with if cross and it works great and somebody else uses an older cabal where cross-compilation is more broken and it fails? How bad is that? Can it be prevented by the fine-grained flags? What else can go wrong with the cross conditional and different versions of stuff?

[andreabedini]

Just some thoughts about cross-compilation.
cabal knows about os and arch through ghc --info. AFAIK it does not have any internal understanding of what cross-compiling is: it "just" calls ghc.

I understand now that by "cross-compiling" we mean: using cabal with a cross-compiling ghc. I guess in this case, an hypotectical build-os/host-os (-and build-arch/host-arch I guess) could come from ghc.

But, in the soon future, ghc will be multi-target so will have a single compiler that can compile for multiple os/arch. I believe in this case cabal will need to learn about cross-compilation because it will have to somehow tell ghc the target to compile for.

W.r.t. granular feature flags, I think we could have a generic way to pass information from ghc --info to cabal. Note that will end up being an input to the solver like extensions and languages are now.