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...