hashable 1.4.6.0 build failure

[chenrui333]

👋 while trying to update some brew formulae, ormolu and fourmolu, seeing some build failures as below:

  Building library for hashable-1.4.6.0..
  [ 1 of 10] Compiling Data.Hashable.FFI ( src/Data/Hashable/FFI.hs, dist/build/Data/Hashable/FFI.o, dist/build/Data/Hashable/FFI.dyn_o )
  clang: error: the clang compiler does not support '-march=native'

[phadej]

According to https://stackoverflow.com/a/72597669 clang-15 supports -march=native. Otherwise turn arch-native flag off.

[chenrui333]

make sense, looks like only happens for monterey-arm build.

[hasufell]

Why is this flag on by default if it:

• breaks with some compilers
• makes binaries less portable

[Mikolaj]

We are just releasing cabal 3.12.1.0. How do we prevent this happening to users of our binaries?

[Kleidukos]

@phadej Hi, may I ask you if you could perhaps do a release of hashable without the non-portable CFLAG as default? :)

[soulomoon]

Relating to #308

[phadej]

Ok, so if you care about performance of your application, you will profile your application, and enable the flag in the future.

I'll turn it off. For the record, on my machine you lose 20% of hash performance, which for hash intensive things will matter. (And if your application is not hash intensive, don't use hashable/unordered-containers, use ordinary containers).

Benchmark              without   with            
hash/Text/strict/11    1.481e-8  1.289e-8 -12.95%
hash/Text/strict/128   0.319e-7  0.263e-7 -17.73%
hash/Text/strict/2^20  2.220e-4  1.252e-4 -43.61%
hash/Text/strict/40    1.934e-8  1.714e-8 -11.37%
hash/Text/strict/5     1.194e-8  0.995e-8 -16.64%
hash/Text/strict/512   0.778e-7  0.649e-7 -16.62%
hash/Text/strict/8     1.215e-8  0.983e-8 -19.09%
Geometric mean         0.810e-7  0.644e-7 -20.47%

[wz1000]

I think it may also be a good idea to mark the affected versions of hashable as deprecated on hackage to prevent them from being inadvertently pulled into any build plans in the future.

[phadej]

deprecated on hackage to prevent them from being inadvertently pulled into

This is common misconception. Deprecating on the Hackage is only a soft constraint. cabal-install will violate it if forced. And if there are no tight constraints, it won't not pick the later version. So deprecation essentially only changes the color of the version on the Hackage page.