Comments (13)
since cabal 1.20 works on ghc 7.6.3, i agree with you
from libclang.
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.
from libclang.
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.
from libclang.
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.
from libclang.
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" [email protected] 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
.
from libclang.
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.
from libclang.
(I noticed some of these issues partially because of my difficulties in getting Hackage to accept my upload of voyeur
.)
from libclang.
@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.
from libclang.
@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.
from libclang.
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.
from libclang.
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.
from libclang.
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.)
from libclang.
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.
from libclang.
Related Issues (20)
- LibClang won't build on the Haskell Platform 2013.2 because greencard is broken HOT 2
- libpthread symbol error? HOT 3
- Provide access to libclang headers needed for accurate parsing HOT 3
- Libclang on hackage doesn't compile (github master does compile) HOT 7
- Pull boundary values out of enumerations
- Make LibClang version track LLVM version HOT 2
- Make `newbuild` branch link correctly on OS X HOT 21
- Use --with-clang-resource-dir configure option HOT 1
- hackage greencard dependency won't build on 7.8 HOT 2
- Crash when trying to enumerate Top Level Headers HOT 3
- Clang.File.getIncludedFile causes segfault on any code HOT 1
- Add an option to use out-of-tree llvm and clang HOT 4
- De-couple from Greencard HOT 3
- New release? HOT 2
- 3.4.0 Haddock Docs Have Not Been Built HOT 1
- Installing via Stack fails due to missing dist/build/Clang/Internal/FFI.chs.c HOT 1
- Doesn't build under Ubuntu HOT 3
- Doesn't build with ghc 8.0.1 HOT 2
- Static builds HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libclang.