Cabal: autogenModulesDir will break ekmett's Setup.hs

[phadej]

The https://github.com/ekmett/bound/blob/master/Setup.lhs used to workaround issues with doctest uses at least autogenModulesDir which signature is changed in 90e908b80b327c4636c21627b0e2a54a6a8d4e4f

I'm not sure whether we can provide non-breaking upgrade path, as we want to write Build_component_name into components autogen dir, but use cabal_macros.h from libraries autogen directory.

Still, I think that it be kind from us, if we try to make possible for ekmett to support wide ranges of bounds for his libraries.

[ezyang]

The most expedient thing to do is to bring back autogenModulesDir, mark it deprecated, and have it point to the library autogenerated directory which may or may not work. However, while this will let all old setup scripts compile, it will silently break any setup scripts which expected the macros to apply to ALL components of the package, rather than just the library. This matters a bit for, e.g., executable packages.

To overcome this BC problem, we can have autogenModulesDir instead point to some sort of "simulated" autogenerated module directories which mimics the Cabal 1.24 and older behavior. In particular, we would write an EXTRA cabal_macros.h file which would record the behavior of all components. Ideally packages wouldn't use this function because it means a lot more recompiling e.g. when you enable/disable tests.

For maximal backwards compatibility, this new, extra cabal_macros.h file would live in the same location as the legacy one, with us changing where the libraries-only macros file lives.

I will write the patch, as long as we decide what to do.

[23Skidoo]

Can't @ekmett use custom-setup?

[ezyang]

We haven't convinced him to use this feature yet ;)

[23Skidoo]

IMO a better migration path would be to add a custom-setup section and then in Setup.hs do something like

#ifndef MIN_VERSION_Cabal
#define MIN_VERSION_Cabal(x,y,z) 0
#endif

#if !MIN_VERSION_Cabal(1,26,0)
[...]

This should be backwards-compatible with old versions of Cabal and cabal-install. We should clearly document in release notes which APIs got broken, though.

[ekmett]

If I add a custom-setup stanza, what happens when a user tries using their already-installed older version of cabal?

[23Skidoo]

It'll be ignored with a warning about unrecognised stanza.

[hvr]

@ekmett as @23Skidoo says, cabal will ignore (but warn) about the unrecognized stanza. Also, custom-setup sections can be added via .cabal-editing.

Here's an example which can be easily tested with GHC 7.8.4 and pre-1.24 cabals: https://hackage.haskell.org/package/base-noprelude-4.7.0.2/base-noprelude.cabal

[ekmett]

I think I can bring myself to spew warnings at old users.

[phadej]

@23Skidoo custom-setup doesn't work as well as we would like it to: https://github.com/haskell/cabal/issues/3424

[ekmett]

So with #3424 we can't safely rely on the defines actually being present on 1.24 at the moment. =/

It seems @glguy has an awful OverlappingInstances-based typeclass trick that can work around at least the autogenModulesDir part.

[ezyang]

I think that's overrepresenting the severity of #3424. You can simply assume that the version is 1.24 or earlier if the macros are not present; in GHC 8.0, GHC provides version macros too, so you'll get the defines one way or another.

Also an update for people who are on this ticket, we added a BC shim so autogenModulesDir now has the old type signature.

[glguy]

Cabal-1.22 and 1.24 don't provide the same API (so assuming missing macros meaning that things are 1.24 or earlier isn't generally helpful), there a types that only exist in one or the other. So for many Setup.hs possibilities #3424 means that we need to fall back to type class tricks or Template Haskell to make a portable Setup.hs

[ekmett]

Annoyingly, Template Haskell doesn't make a sufficiently portable Setup.hs for the distributions that give us only stage1 builds and can't run TH though. Life is hard. ;)

[ezyang]

Anyway it's fixed.