Open
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.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
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
up
anddown
, wheredown
depends onup
.up
is passed options to make the generated object code more efficient, butdown
isn't. If code fromup
then gets inlined intodown
then 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.