Having trouble satisfying cabal #5
Comments
|
I’ll have to give this a longer answer once I’m at my desk. For now it looks like you run afoul of the 8.4 base. Did you try passing |
|
So...
This should be Together with the Let me know how it goes! |
|
Ok great, I definitely made progress (cabal HEAD was needed for new-update, but then it worked great). Now I'm running into trouble building unordered-containers, as it hasn't been updated for the monoid/semigroup changes yet, but I can go ahead and make PR for that. I guess I'll leave this issue open for now in case I run into other problems. Thanks so much! |
|
Ahh right, I forgot to mention that you need a |
|
Thanks! That got me a lot further. I'm failing on zlib now: |
|
That’s due to the cabal bug (failing to pass down flags to dependencies) i believe. Unpack zlib into your project folder (and apply the zlib patch: haskell/zlib#14). |
|
Awesome, more progress. :) Any idea on these? |
|
So |
|
I ended up bringing them down and changing the build type to Simple (as well as a bunch of ekmett's other packages), and that worked. Now all the deps are out of the way, onto getting my own code running! ;) |
|
Yes. The non-simple buildtypes are an issue for cross compilation and cabal right now. This is made worse by the abuse of the custom build type to add doctest support. This is a tricky question though. I still believe that non-simple buildtypes should be avoided as much as possible and we ought to provide cabal with less opaque facilities. E.g. cabal doctest/cabal new-doctest. |
|
Ok, all my library code is built and I'm ready to build the static library. But my question is- in your iOS cross compiler blog post, when building the static lib, you link in a custom built libffi. But since I'm using your relocatable cross-compiler, do I still need to do that? I.e., do I need to custom build a libffi? And will there be any problem if it's not the exact same libffi that you linked into the cross compiler? |
|
I believe the libffi that's shipped with the binary distribution should be good to go; just give it a try :) The issue with the libffi library is essentially just an issue llvm has with it. LLVM started supporting only the unified assembly syntax, while the latest libffi release still used some older assembly syntax. My suggestions is, just use |
|
Well, I'm not sure if you have any ideas on this but... When I try to build in xcode I get a linker error: I'm linking in the libhs.a file I built, so my understanding is that it should have In case it matters, I get these warnings when building the archive: |
|
The warning don’t matter. But I believe you have the mains wrong. Your entry point is the main defined in main.m, which then calls your Haskell library. Having your Haskell library take over the main entry is something I have not explored. Essentially the main function is the initial entry point. And this has always been the application logic, which then only called out to haskell. |
|
Ah yea, I had followed a different example in the past that did it that way. But I did change it as you suggested and got it working in the simulator! Thanks so much for your help! I'll close this for now and open another issue if I run into another problem. Thanks again! |
|
Awesome! 👍 Let me know if you get it working on the device as well :) |
|
Hmm, it would be super interesting if the steps taken here could perhaps be formulated in a list of steps or something? It was a bit confusing following :) |
|
@Tehnix yes, definetly! I plan to setup a read the docs repo this week, and start documenting it. There's also haskell/cabal#4972, which might help a lot. I wanted to try that out prior to writing anything down. With the meetup presentation coming up in two days, I hope to be able to get everything done this week. |
|
Fantastic! Btw, is the meetup talk about haskell on mobile (and in that case, is it recorded)? |
|
Yes it is, see https://www.meetup.com/HASKELL-SG/events/246341959/ Unless screw up the microphone battery again, it should be properly recorded |
|
Once I'm happy with my Haskell/OpenGL/iOS setup I plan to fully document the steps necessary to recreate it. |
|
Would you be willing to contribute to a shared document? |
|
Definitely, yea. |
|
So I've started some stub here: http://mobile-haskell-user-guide.readthedocs.io/en/latest/ which is essentially mobilehaskell/user-guide feel free to contribute however you like, even if it's just issues, what should be documented. I hope I'll be able to get |
|
@asivitz with haskell/cabal#5018, you should not need to unpack or add packages as sub modules anymore. I'll add a copy of hvr/head.hackage#22 to this repository tomorrow, which should make adding and sending patches (e.g. change build-type to Simple) much simpler, so we can share common patches to packages and everyone benefits. |
|
Sounds good; I'll PR my changes once you push that out. I'm not sure exactly what that cabal patch allows you to do; does it let you change the build type via the command line? |
|
To clarify- unpacking by itself didn't never fixed a package for me. I had to change the build type to Simple in order to get things to compile. |
|
@asivitz unpacking / git submoduling only helps if the package can be used unmodified, but needs the flags to be passed (e.g. foundation, basement, ...) that's what the cabal PR helps with. For modifying package (e.g. changing build type from custom to simple), that's what the overlay is for. I hope I'll have it fully automated by the end of the day, and adjusted the copy of hvr/head.hackage#22 to deal properly with That should allow you to use Ideally all of us would contribute overlay patches to the hackage.mobilehaskell.org repository, and could benefit from the patched packages. I'd really like some way to upstream those patches automatically, but I haven't found one yet. If cabal packages would provide source (git, tag) for the release, that would probably work, but not all do. Maybe we can make cabal provide those fields and encourage them to be set. At that point the script could automatically open Pull Requests against the original source packages. |
Not sure if this is the best place to post when looking for general help, but here's where I'm stuck:
I have a couple packages that I typically build using stack (cabal new-build is a bit unfamiliar to me). I added a cabal.project file with the following contents:
I also have llvm5, the toolchain-wrapper, and the cross platform ghcs in my path.
Now I run
x86_64-apple-ios-cabal new-buildand I get...First of all, the warning about the missing package list does not go away when I run
cabal updateorx86_64-apple-ios-cabal update. I'm not sure if that's a real problem...But I'm not sure how to deal with the dependency mismatches. Should I just go read more cabal documentation, or is there something I should know about the versions of packages used in the mobile hackage overlay? If it helps, here's the package.yaml of my library
Hickory, which I guess is the start of the problem: https://github.com/asivitz/Hickory/blob/master/package.yamlAlso, thanks for all your hard work on mobile haskell!
The text was updated successfully, but these errors were encountered: