search

haskell / cabal

Official upstream development repository for Cabal and cabal-install
https://haskell.org/cabal
Other
1.61k stars 691 forks source link

Informing the end-users about best practices for packaging Haskell code with(out) non-portable C flags. #10141

Open Kleidukos opened 2 months ago

Kleidukos commented 2 months ago

Some package authors will want to enable C flags for their FFI C code in order to get good performance (or avoid terrible performance) by default for their users. However some of these flags are not portable across compilers and versions.

-march=native for instance, gives a solid performance boost, but is unsuitable for distributing binaries. We should probably encourage the pattern of having a cabal.project for local development and a cabal.release.project file that enables it.

This information would be located in the user guide's How to package Haskell code section.

TeofilC commented 2 months ago

One thing to note as well is that such flags can be very fragile in the presence of inlining (as I mentioned here: https://github.com/haskell-unordered-containers/unordered-containers/pull/483#issuecomment-2077438685)

Suppose you have two packges up and down, where down depends on up. up is passed options to make the generated object code more efficient, but down isn't. If code from up then gets inlined into down then it will be compiled with the flags for down, and so the extra optimizations won't fire.

Because you can't know how code will get inlined, it's best to apply these flags to your entire project or not at all. Otherwise you can have confusing behaviour, eg, your code may be faster if stuff doesn't get inilned. Alternatively you have to be very careful that no code that depends on the flags can be inlined.

Kleidukos commented 2 months ago

Because you can't know how code will get inlined, it's best to apply these flags to your entire project or not at all.

Yes that's what I would recommend, with a good ol' package * stanza.