Cannot find generated header files when building unix-time with Cabal 2.2

[pechersky]

I have been trying to build hoogle using cabal new-build hoogle. It fails on building unix-time with fatal error: config.h: No such file or directory.

This is likely due to a missing include-dirs: cbits in the cabal file for unix-time. This was determined by a successful build of kazu-yamamoto/unix-time release v0.3.7 by including that missing line. The build succeeded with cabal new-build.

This was found using cabal-install 2.2.0.0, ghc 8.0.2, WSL Ubuntu 16.04.

[hvr]

An important detail here is that this used to work in cabal-2.0

[hvr]

I was able to confirm my suspicion about #4874 being the culprit:

• 783cbe6 exhibits the regression
• whereas the parent commit c094940 doesn't have the regression

Now the question is if we can recover support for old packages by extending the include header searchpath to the new locations, and/or whether this was an unintentional regression or an intentional one (in which case we may want to consider a legacy fallback for older cabal-version:... spec versions; OTOH, I'm not sure if unix-time wasn't doing something that should have never worked to begin with). Fwiw, I don't think that many packages are affected, as otherwise we would have noticed this sooner.

/cc @23Skidoo @angerman

[hvr]

While this doesn't make this issue go away, the author of unix-time mitigated this by via http://hdiff.luite.com/cgit/unix-time/diff?id=0.3.8&id2=0.3.7 (c.f. kazu-yamamoto/unix-time#42)

[angerman]

I'm kind of on the fence to say this was broken to begin with...

[hvr]

I tend to agree w/ @angerman as I'm having a hard time coming up with a legacy fallback which doesn't disable new principled scheme from #4874 for legacy specVersions. Maybe we have to sacrifice the buildability of prior unix-time releases as there's not much we can do in a non-magical way IMO.

[RyanGlScott]

This also breaks the ability to new-build the time library with cabal-install-2.2, as documented in #5223 (comment).

[gbaz]

time is so pervasive that breaking with that seems like it pushes up the need for a fix here...

[gbaz]

also as noted on that ticket "in the time case, the include-dirs: lib/include is there" so maybe its more possible to have a solution...

[hvr]

Fwiw, the issue in #5223 is in a different phase: This is about about install-includes referring to an auto-generated header file which lib:Cabal is trying to locate (but looks in the wrong place; ideally we'd have the equivalent of autogen-modules for include header files, then cabal would know the single place where to expect that file, rather than have to try two places), rather than an -I flag not being passed to GHC (and GHC complaining).

[hasufell]

Still a problem in 2020 building old unix-time.