Repository navigation
Informing the end-users about best practices for packaging Haskell code with(out) non-portable C flags. #10141
Description
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.
Reacted by Mikolaj Konarski
Activity
TeofilC commentedon Jun 24, 2024
One thing to note as well is that such flags can be very fragile in the presence of inlining (as I mentioned here: haskell-unordered-containers/unordered-containers#483 (comment))
Suppose you have two packges
upanddown, wheredowndepends onup.upis passed options to make the generated object code more efficient, butdownisn't. If code fromupthen gets inlined intodownthen it will be compiled with the flags fordown, 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 commentedon Jun 24, 2024
Yes that's what I would recommend, with a good ol'
package *stanza.