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.

[hasufell]

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.

You can change the base dependency to base < 0, which is sometimes done to make a package non-installable: https://hackage.haskell.org/package/unix-2.8.2.0/revisions/

[phadej]

@hasufell I know, but that is not marking as deprecated it's making a package version uninstallable with an unsatisfiable constraint trick

[hasufell]

@hasufell I know, but that is not marking as deprecated it's making a package version uninstallable with an unsatisfiable constraint trick

Correct. As Zubin pointed out the motivation is:

to prevent them from being inadvertently pulled into any build plans in the future

This can be achieved with said trick.

[chenrui333]

Thanks for the fix, now the issue is gone for homebrew builds. 🙏

[hasufell]

Remote cabal.project files could also be used to create a set of constraints that try to achieve maximum performance (text +simdutf and hashable +arch-native for example).

This constraint set could then be maintained centrally and also serve as documentation.