I need the the following library for my development: gtksourceview2.
However, gtksourceview2 is broken:
gtksourceview2-0.12.3.1 broken with cabal because of duplicate code
what can I do to install it anyway? I can change the haskell files if I know how I can do that when running cabal install.
Distribution.Simple.Utils.moreRecentFile function comes from Cabal, it was added in 1.18.* series. gtksourceview2 uses custom build script, and it is very sensitive to changes in Cabal library. Try to install it using older Cabal version. E.g. cabal install gtksourceview2 --cabal-lib-version=1.16.0
Related
I am working on a Haskell package. I have not yet uploaded it to Hackage and the version number is 0.1.0.0. I am using new style Cabal commands.
In order to test the package while I'm working on it (to make the library available to the test project), I run cabal new-install --lib after building the package.
However, I noticed that bug fixes were not having any effect and my test project (which is not itself a Cabal project and consists of a single Haskell file) continues to behave the same way even when I build and install the library.
So, I've tried modifying the cabal new-install --lib command with various combinations of flags like --force, --force-reinstalls and --reinstall. This did not have any effect.
Neither did deleting all generated files in both the library and the test project and re-building the library before recompiling the test project.
One possible solution might be to increase the version number. However, since the package is not released yet, I do not want to start using up version numbers before I upload it to Hackage. Even after I release it, I would like to change the version number only when I actually upload the new version to Hackage, not every time I test out a minor change on my own PC.
The old Cabal commands behave just fine. However, is there any way to get new-install to reinstall the package whenever I fix a bug without changing the version number?
I found a bug report from 2012 that might be relevant but I must admit that I do not understand it very well since I'm completely new to Cabal. https://github.com/haskell/cabal/issues/294
I created a cabal library inside a sandbox with the following commands:
cabal sandbox init
cabal init
I added the line documentation: True to cabal.config to make sure that documentation is generated, and I added a dependency to the vector package in mylib.cabal. Then I ran:
cabal install --only-dependencies
I got the following output:
/scm/hs-proj/.cabal-sandbox
Configuring primitive-0.6...
Building primitive-0.6...
Installed primitive-0.6
Configuring vector-0.10.12.3...
Building vector-0.10.12.3...
Installed vector-0.10.12.3
Updating documentation index
/scm/hs-proj/.cabal-sandbox/share/doc/x86_64-osx-ghc-7.10.1/index.html
So far so good.
When I opened the index file it contained links to a lot of packages, like:
file:///scm/hs-proj/.cabal-sandbox/share/doc/x86_64-osx-ghc-7.10.1/Data-List.html
file:///scm/hs-proj/.cabal-sandbox/share/doc/x86_64-osx-ghc-7.10.1/Data-Vector.html
But of these links pointed to any real files. Note that this is the case for the extra dependencies like vector and also for built-in packages list Data.List.
So I think I've installed the documentation incorrectly. Can someone point out how I've installed the documentation incorrectly and how to do it correctly?
It's not your fault, this is a known bug in haddock.
It only affects ghc 7.10, so a workaround could be to use ghc 7.8.4 until this is fixed.
If a have a library checked out locally that builds with cabal that is used by an application. I would like to build my application against the the local library rather than something from hackage but I'm not sure how to do this. This seems like something I should be able to do, I'm just don't seem to be able to work out how.
Sandboxing
In case it matters or complicates things, the application is in a cabal sandbox with the cabal-sandbox-config file in the route directory of the application.
What I'm Trying to accomplish
I'm building Yesod application and I want to tweak the behaviour of one of the dependencies (shakespeare). I would like to build my application against my tweaked version.
Use cabal sandbox add-source, which is designed specifically for this use case.
Example:
$ git clone https://github.com/SomeUser/SomeDependency
$ cd /path/to/my-project
$ cabal sandbox add-source /path/to/SomeDependency
$ cabal build
As a bonus, if you later update SomeDependency and try to rebuild my-project, cabal will notice that and reinstall SomeDependency.
Option 1:
You can just clone the project, and then run a cabal install in the cloned directory.
git clone https://github.com/yesodweb/shakespeare.git
This will give you a directory shakespeare which will contain a .cabal file.
So just enter the directory and run a cabal install. This will install shakespeare. Now continue with installing your project.
The key point:
You need to install shakespeare yourself first so that when you compile your own project, ghc or cabal doesn't try to install the shakespeare dependency (from hackage by default) on its own.
Option 2:
Install hackage-server
Upload a copy of shakespeare (your tweaked version) to your local hackage
Edit your cabal config to prioritize your local hackage over the haskell-hackage
remote-repo: hackage.haskell.org:http://hackage.haskell.org/packages/archive
remote-repo: local.hackage:http://local.hackage/packages/archive
This might make sense if you're going to be tweaking several packages, but you're probably better off not doing this because among other things, keeping track of updates to your tweaked versions is going to be a nightmare.
When I run cabal install c2hs, it seems to finish correctly, but doesn't register the package. The package seems as if it's not even installed: it doesn't show up in ghc-pkg list, and rerunning cabal install c2hs goes through the same install procedure, instead of saying "All the requested packages are already installed".
I'd much appreciate any help getting this up and running. I'm using the prebuilt GHC 7.4.1 binary.
cabal install output: http://pastebin.com/CRUii8mm
imports are defunct: http://pastebin.com/r0aypxRA
Thanks in advance!
I believe c2hs is an executable, not a library. The cabal install output that you provided shows that the execeutable is placed in your private .cabal/bin directory.
The C2HS module has been removed from newer versions of c2hs, since sometime prior to c2hs-0.15. If you check out the c2hs source tree, you could find it by going back through the revisions. Or some other libraries include it. There's more information in this trac ticket. C2hs is moving towards making the functions in C2HS.hs completely unnecessary, although they aren't quite there yet (floating-point formats in particular need to be manually marshalled).
I'm working on the wxHaskell library, and wishing to keep my development work separate from the stable wxHaskell from hackage I'm using cabal-dev in the following manner:
I obtained the source for wxHaskell from darcs;
Because wxHaskell is comprised of three components I used cabal-dev add-source to add each one (wx, wxcore, wxdirect);
I was then able to install into a sandbox local package library by doing cabal-dev install wx, as expected, the dependencies were detected and everything built and installed.
Finally I successfully ran my test code by using ghc -package-conf to specify the location of the sandboxed package database.
The problem comes when I make modifications to the wxHaskell source. In order to build and install the updated code I have to use cabal-dev install --reinstall, which makes sense as I don't increment the version number; the build takes place and I see "Installing library in..." and "Registering..." but the changes I've made in the code aren't present in the recompiled sandbox library.
The work around I have at the moment is to delete the cabal-dev library and repeat the process every time I want to rebuild.
UPDATE: cabal-install >= 1.18 has support for sandboxes, and will be better maintained than cabal-dev going forward. Cabal-install also has better support for using add-source with sandboxes. Here's a description of the new sandboxing features in cabal-install: http://coldwa.st/e/blog/2013-07-30-Cabal-sandbox.html
Old answer:
As you found, 'add-source' is not meant for use with actively changing projects. I'm not sure that there is a good solution there either - it's difficult to track the location of an add-source'd project (there is no existing infrastructure for that, at least), and I'm not sure that's always the right thing.
Another workflow may serve you better - just use cabal-dev install, pointing to the sandbox you wish to use for future development. Recent versions of the cabal toolchain (by which I mean Cabal, cabal-install and cabal-dev) allow for this sort of thing:
$ ls
wx wxcore wxdirect
$ cabal-dev install --sandbox=<path-to-some-sandbox> ./wx ./wxcore ./wxdirect
...
(Note: I have not tested this with WX - kinks may arise that I'm unaware of!)
Assuming everything goes as expected, that will install the three packages from the local sub directories into the specified sandbox. Updating the source just means re-issuing a cabal-dev install command for the project that changed.
Keep in mind that you must either issue the repeated cabal-dev install commands in the correct order on your own, or you must use the batch command above and update version numbers accordingly.
I make no claims about this being ideal ;) but I think it's better than deleting the sandbox each time.
After some investigation I can confirm that this is a result of my misunderstanding regarding the usage of add-source, as detailed in "Using a sandbox-local Hackage" section of the README, which is given here (the strong was added by myself and indicates the reason for my misunderstanding):
Cabal-dev also allows you to use un-released packages as though they
were on hackage with cabal-dev add-source.
For example, the linux-ptrace and posix-waitpid packages were only
recently uploaded to hackage. Previously, cabal-dev was used to build
applications that depended on these two packages:
$ ls
linux-ptrace/ myProject/ posix-waitpid/
$ cd myProject
$ cabal-dev add-source ../linux-ptrace ../posix-waitpid
$ cabal-dev install
Note that cabal-dev add-source accepts a list of source locations.
Be careful, however, because packages that have been added are not
tied to their original source locations any more. Changes to the
linux-ptrace source in the above example will not be used by
myProject unless the user issues cabal-dev add-source with the
path to the linux-ptrace source again. This is similar to the
cabal install step you may do now to enable a project to make use of
changes to a dependency.