The compiled code will need to run on hostPlatform

[andreabedini]

I admit I am a dog at cross-compilation but the nixpkgs manual says

The "host platform" is the platform on which a package will be run. This is the simplest platform to understand, but also the one with the worst name.

When we:

• build blst
• as part of a linux build tool
• that is needed to compile something for mingw64

then blst gets configured with ./build.sh flavour=mingw64\n./build.sh -shared flavour=mingw64 while it's actually built on linux and for linux (where the build tool will run).

Using hostPlatform seems to make this work ok.

[michaelpj]

This is definitely better. I am almost 100% sure that targetPlatform is wrong - the target platform should only matter for compilers!

[michaelpj]

I'm quite surprised this hasn't bitten us already given how much cross-compilation we do...

[angerman]

I agree that targetPlatform most likely was wrong.

[andreabedini]

The nixpkgs manual has a big blurb about targetPlatform (see blow). From my little understanding it's the a build tool to cross compile situation that is uncommon. This is where targetPlatform != hostPlatform. Here the "ultimate target" is mingw64.

The “target platform” attribute is, unlike the other two attributes, not actually fundamental to the process of building software. Instead, it is only relevant for compatibility with building certain specific compilers and build tools. It can be safely ignored for all other packages.

The build process of certain compilers is written in such a way that the compiler resulting from a single build can itself only produce binaries for a single platform. The task of specifying this single “target platform” is thus pushed to build time of the compiler. The root cause of this is that the compiler (which will be run on the host) and the standard library/runtime (which will be run on the target) are built by a single build process.

There is no fundamental need to think about a single target ahead of time like this. If the tool supports modular or pluggable backends, both the need to specify the target at build time and the constraint of having only a single target disappear. An example of such a tool is LLVM.

Although the existence of a “target platform” is arguably a historical mistake, it is a common one: examples of tools that suffer from it are GCC, Binutils, GHC and Autoconf. Nixpkgs tries to avoid sharing in the mistake where possible. Still, because the concept of a target platform is so ingrained, it is best to support it as is. 

[andreabedini]

please try building cardano-base against this before merging

I'll let hydra do that for me :joy: https://ci.iog.io/jobset/input-output-hk-cardano-base/pullrequest-434

Edit: that was quick, it looks like there are no changes at all.