Couldn't match type ‘ComponentLocalBuildInfo -> String’ with ‘[Char]’

[mhwombat]

Note that I'm using cabal-install version 1.25.0.0 (from the git repo) and ghc 7.10.3. Perhaps this is a bug in the new cabal-install? Unfortunately, I don't understand the error message well enough to tell.

$ cabal install
Resolving dependencies...
Notice: installing into a sandbox located at
/home/eamybut/nosync/sandboxes/distributive
Configuring base-orphans-0.5.4...
Configuring tagged-0.8.3...
Configuring transformers-compat-0.5.1.4...
Building base-orphans-0.5.4...
Building tagged-0.8.3...
Building transformers-compat-0.5.1.4...
Installed transformers-compat-0.5.1.4
Installed tagged-0.8.3
Installed base-orphans-0.5.4
Configuring distributive-0.5.1...
Failed to install distributive-0.5.1
Build log ( /home/eamybut/nosync/sandboxes/distributive/logs/distributive-0.5.1.log ):
cabal: Entering directory '.'
cabal: Leaving directory '.'
cabal: Error: some packages failed to install:
distributive-0.5.1 failed during the configure step. The exception was:
user error ('/usr/local/ghc-7.10.3/bin/ghc' exited with an error:

dist/dist-sandbox-4b8dde2c/setup/setup.hs:28:50:
Couldn't match type ‘ComponentLocalBuildInfo -> String’
with ‘[Char]’
Expected type: FilePath
Actual type: ComponentLocalBuildInfo -> String
Probable cause: ‘dir’ is applied to too few arguments
In the third argument of ‘createDirectoryIfMissingVerbose’, namely
‘dir’
In a stmt of a 'do' block:
createDirectoryIfMissingVerbose verbosity True dir

dist/dist-sandbox-4b8dde2c/setup/setup.hs:31:20:
Couldn't match type ‘ComponentLocalBuildInfo -> String’
with ‘[Char]’
Expected type: FilePath
Actual type: ComponentLocalBuildInfo -> String
Probable cause: ‘dir’ is applied to too few arguments
In the first argument of ‘(</>)’, namely ‘dir’
In the first argument of ‘rewriteFile’, namely
‘(dir </> "Build_" ++ testName suite ++ ".hs")’
)

[RyanGlScott]

Not a bug per se, just an API change in Cabal.

Up until Cabal-1.24, the type signature of autogenModulesDir was:

autogenModulesDir :: LocalBuildInfo -> String

But in the HEAD version of Cabal (1.25), the new type signature is:

autogenModulesDir :: LocalBuildInfo -> ComponentLocalBuildInfo -> String

That's why the error message gripes about Actual type: ComponentLocalBuildInfo -> String, since it wasn't given an argument of type ComponentLocalBuildInfo in this line.

Keep in mind that Cabal-1.25 is pretty bleeding-edge; after all, GHC 8.0 hasn't even been released yet and that will debut Cabal-1.24. Since a bazillion ekmett packages use a flavour of this Setup, I'm loathe to start patching up every single one of them to accommodate an API that's still in a heavy state of flux. So the way I see it, your options are:

1. Don't use Cabal-1.25 to build distributive and friends.
2. Before building distributive and friends, find a way to patch up the Setup script. You have two values of type ComponentLocalBuildInfo (libcfg and suitecfg). I'm not sure which one you're intended to use to retrieve the autogen directory.

[mhwombat]

That's grand, so. I've downgraded to an earlier version of Cabal and cabal-install.

[ezyang]

Hey guys. Cabal is willing to update code to make the BC break less severe. The reason autogenModulesDir changed types is because each component gets its OWN autogenerated files directory. This is a good thing, because it means that if Cabal reconfigures a single component (and, e.g. cabal_macros.h changes) we only rebuild the component it affected, and not EVERYTHING (which was what happened before.)

So, I could imagine reverting autogenModulesDir to the old type, and stating this is the "global" autogen directory which is added to the include path of all modules (and we'd introduce a new function for the per components functionality.)

In the particular case here, it's a pretty easy refactor to use the new API: calculate dir with suitecfg (because the autogen module is going to be used by the test suite, not the library). Let me know what you'd like to do. CC @ekmett

[ekmett]

If at all possible I'd like to be able to build code across old and new versions of cabal.

Beyond that I care very little about what goes into the sausage we make.

Reopening this because unless there is a change, or a workaround we figure out, or something then this really will be an issue.

[ezyang]

when GHC 8.2 comes around, will your support window assume a cabal-install that knows how to deal with custom-setup? Then you can start macros and things are easy.

[ekmett]

distributive has a pretty painfully wide support window, given that it sits under almost every single package I maintain. It currently builds with ghc 7.0+ and cabal-version: >= 1.8.

I'd really like to be able to keep supporting older GHCs and distributions with this package in particular, because otherwise I have to commit to cutting off support for everything I write on older GHCs.

In the absence of breaking builds on older cabals, if I put a {-# LANGUAGE CPP #-} directive in an older cabal file, can I look around for a newer #define of some sort to figure out if I have new behaviors?

[ezyang]

Yes, if you add a custom-setup, for all versions of cabal-install which understand it, you will get a Cabal version macro.

[ekmett]

But, if I add the tag to my cabal file, I have to bring the cabal-version bound up through the stratosphere, destroying backwards compatibility, no?

[ezyang]

No, custom-setup specifically doesn't require you to bump cabal-version (it was specifically to avoid this problem). So the worst that will happen is that old Cabal users will see a "not understood stanza" error.

[RyanGlScott]

An example of this in the wild is glib (see its .cabal file here). Here's an example of the warning that is emitted when glib is built using an older version of Cabal.

[RyanGlScott]

Also, if you want to quickly work around this problem when building distributive with GHC HEAD, here's the changes I had to make (also mentioned in ekmett/bifunctors#50):

diff --git a/Setup.lhs b/Setup.lhs
index 46dc623..51fd42a 100644
--- a/Setup.lhs
+++ b/Setup.lhs
@@ -24,10 +24,10 @@ main = defaultMainWithHooks simpleUserHooks

 generateBuildModule :: Verbosity -> PackageDescription -> LocalBuildInfo -> IO ()
 generateBuildModule verbosity pkg lbi = do
-  let dir = autogenModulesDir lbi
-  createDirectoryIfMissingVerbose verbosity True dir
   withLibLBI pkg lbi $ \_ libcfg -> do
     withTestLBI pkg lbi $ \suite suitecfg -> do
+      let dir = autogenModulesDir lbi suitecfg
+      createDirectoryIfMissingVerbose verbosity True dir
       rewriteFile (dir </> "Build_" ++ testName suite ++ ".hs") $ unlines
         [ "module Build_" ++ testName suite ++ " where"
         , ""

[RyanGlScott]

I've started a cabal-1.25-fix branch with what I believe are the necessary changes to solve this issue on all versions of Cabal, but I'll hold off on merging it for now in case there are further Cabal changes in the future.

[ezyang]

This might also be of interest: haskell/cabal#3576

[thomie]

Cabal is willing to update code to make the BC break less severe.

Yes please. This change broke half the internet for me.

[ezyang]

OK, well, here you go.

[RyanGlScott]

@ezyang: For those who want to expunge deprecation warnings from their code: is it sufficient to simply change autogenModulesDir to autogenPackageModulesDir (aside from the warnings you get from using InstalledPackageId)?

[ezyang]

Absolutely not. You should look at the use-site of autogenModulesDir and determine if you wanted the autogenerated modules directory for your component, or if you were trying to apply it to everything. For example, in @ekmett's setup script, he wanted to generate these modules one per component (and in fact had a workaround in place to make sure that they didn't clobber each other with old Cabal.) As an extreme case, if you are trying to find the Paths module or the cabal_macros.h file, they no longer exist in autogenModulesDir, because they truly are per-component affairs, and I did not write a BC shim for a "package global" version of the module/macros file. (If people yell and shout, yes, I can write a BC shim for that too.)

[RyanGlScott]

Ah, thanks for clearing that up. I'll make it a point not to use autogenPackageModulesDir for these types of scripts then.

And I agree that we should be working on porting these scripts to use autogenComponentModulesDir in the future. But seeing as how that will take some time, and we've got lots of disgrunted folks who want to lens on GHC HEAD in the meantime, this BC shim is a welcome panacea. Thanks, @ezyang.

[ezyang]

Well, the reason why autogenPackageModulesDir exists is because I do think there are some cases where this is what people wanted. But I'd certainly like people to think about it and that's why there's a really long deprecation message attached to autogenModulesDir :)

[ekmett]

I think I can adapt a trick from @glguy to make this work portably.

[RyanGlScott]

hvr's Ubuntu GHC PPA now has a GHC HEAD build that incorporates this commit, which restores the (now-deprecated) autogenModulesDir function. This means that distributive now builds on GHC HEAD! Hooray!

We still need to port over all of @ekmett's Setup scripts to use autogenComponentModulesDir, but I'll hold off on that until Cabal-1.26 is closer to release. The proximal issue (distributive failing to build with GHC HEAD) has been fixed, so I'll close this issue.