Cabal 1.20 breaks Setup.hs

[sethfowler]

createArLibArchive takes different arguments with cabal 1.20.

We could potentially fix this with an upper bound on the cabal version, but given that cabal 1.20 works on GHC 7.6.3 I'm inclined to update Setup.hs to work with the new version and bump our cabal lower bound.

I'll go ahead and do that, but I'll leave this open for a bit in case others want to chime in.

[ghorn]

since cabal 1.20 works on ghc 7.6.3, i agree with you

[sethfowler]

Unfortunately cabal 1.20 has another issue. Install hooks don't run. See here: haskell/cabal/issues/1805

I've determined that copy hooks still run, so we can work around this for now by moving the install hook code to a copy hook. I don't have time to do that tonight, though.

[sethfowler]

An additional wrinkle here is that you can't require cabal 1.20 on Hackage. (It refuses uploads of packages with that requirement.) This is a huge pain since we can't write code involving createArLibArchive that works on both cabal 1.18 and 1.20. The only workaround I know of is Template Haskell. Even CPP won't work because there's no cabal version macro.

I don't know yet what to do here. Thinking about it. The options are:

• Rewrite the code to avoid createArLibArchive.
• Lie about our cabal version compatibility so Hackage will accept the upload, and just mention the issue in the documentation.
• Use TemplateHaskell to write code that actually works with both versions.

[sethfowler]

At this point I'm leaning towards rewriting to avoid createArLibArchive. I don't think I'll have time to give it a shot until this weekend, though.

[chetant]

Why not NOT support cabal 1.20 for now? Almost everyone will have the older
Cabal lib installed. This shouldn't be a show stopper..
On Apr 24, 2014 11:36 AM, "Seth Fowler" notifications@github.com wrote:

At this point I'm leaning towards rewriting to avoid createArLibArchive.
I don't think I'll have time to give it a shot until this weekend, though.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/46#issuecomment-41302212
.

[sethfowler]

Because I was wrong in my first comment: cabal does not allow you to put an upper bound on the supported cabal version. And cabal nags you to upgrade it if there's a newer version available, so over time increasingly many users will have the new version.

I just pushed a library to Hackage yesterday (voyeur) that does that same thing we do in LibClang without using createArLibArchive. Check its Setup.hs if you're curious. It's not that big a deal to avoid it.

[sethfowler]

(I noticed some of these issues partially because of my difficulties in getting Hackage to accept my upload of voyeur.)

[chetant]

@sethfowler even if people do install the newer version, we'll still be able to use the old one. ghc 7.8.2 has Cabal 1.18.1.3 built in. Unless someone does a custom build, they should have non Cabal 1.20 libs.
If however if the fix is trivial, then it doesn't really matter either ways.

[sethfowler]

@chetant It doesn't seem to work that way, unfortunately. As I mentioned, it's illegal to specify an upper version bound on cabal. As far as I can tell, if you're using a version of cabal-install built against cabal 1.20 then when you run cabal install it will use that version of the cabal library. Speaking from personal experience, as soon as I ran cabal install cabal-install I became unable to install LibClang.

[sethfowler]

OK, I've refactored Setup.hs in a way that should work on both older and newer cabal. I also switched from using ar to libtool. Since we can't use createArLibArchive anymore there is little advantage to ar, and switching to libtool instantly eliminates most of the complexity in Setup.hs.

libtool should also let us support dynamic linking correctly, although I didn't add that case to this patch since I haven't had a chance to test it.

The refactored version is on the setup-refactoring branch. I'll merge it to master once I confirm that it works on Linux as well. It's rock solid on OS X.

[sethfowler]

To clarify the above, I mean that libtool will let us support dynamic linking both easily and correctly, since it handles all the cross-platform nastiness for us. We can obviously support dynamic linking without libtool, but it requires that we deal directly with those platform differences and corner cases.

[sethfowler]

Alright, so I finally got a chance to test this branch on Linux and it doesn't work, sadly. Linux's libtool is actually a totally different program, and it doesn't include the feature that I'm using from OS X's libtool.

However, strangely enough, Linux's ar tool includes that feature in a different form. This mailing list post shows how we can use GNU ar to directly merge static libraries.

This should be straightforward to support, but it's a bit aggravating that we can't just use one solution on the two platforms. (Actually, for my other project I was able to support both platforms using ar -r, but that fails for this project. It might be because there are a bunch of collisions between object names, which libtool warns about on OS X. If that's the problem, the simplest solution would be to rename our Haskell modules to avoid conflicts; I may try that and see how it works out.)

[sethfowler]

So I went ahead and implemented the ar -M approach, and it seems to work flawlessly. I tested on both Ubuntu 13.10 and OS X 10.9 with no problems. I'm going to go ahead and merge the branch to master.