Actually, let me clarify my point: I have rarely encountered problems when using Cabal as a package distribution system, but I have run into problems when using it as a build system in a non-trivial manner. For example, when I wanted to build a lot of small utility programs I found that it was re-compiling commonly-shared source files for each program, rather than compiling the source file once and re-using the object file. This was sufficiently annoying that I migrated the build process of my utilities to scons. Having said that, most libraries tend not to have special needs as far as the build process is concerned (unless they are doing complicated things to interface with a foreign framework), so the limitations of Cabal is not usually be a problem in practice, and the Cabal infrastructure makes installing packages very convenient. Cheers, Greg On Nov 8, 2009, at 8:28 PM, Gregory Crosswhite wrote:

I have rarely encountered problems when creating or installing packages using Cabal. In fact, the opposite is the case: I find it annoying when installing packages that haven't been cabalized because they don't pull in all of their dependencies automatically.

It looks like there was a problem building readline, perhaps because it had trouble finding libreadline on your system. If this is the case, then the problem has nothing to do with Cabal but merely with the fact that a single dependent package failed to install. Have you tried building readline by itself and seeing the error message that it gives?

Cheers, Greg

On Nov 8, 2009, at 7:29 PM, Philippos Apolinarius wrote:

...

I made small improvements in the Small Japi Binding, and asked how to make it available. I received a few private messages advising me to build and package the library using a tool called cabal. Since I have used installation tools for PLT, R and LaTeX libraries, I thought cabal was something similar. However, I noticed that there are a lot of complaints against cabal. Therefore, I decided to install cabal, and try it. It seems that it is easier to install packages by hand than using cabal. Here is a typical cabal session:

D:\ghc\ghcapi>cabal update Downloading the latest package list from hackage.haskell.org

D:\ghc\ghcapi>cabal install mkcabal Resolving dependencies... Downloading pcre-light-0.3.1... Configuring pcre-light-0.3.1... Downloading readline-1.0.1.0... Configuring readline-1.0.1.0... cabal: Error: some packages failed to install: mkcabal-0.4.2 depends on readline-1.0.1.0 which failed to install. pcre-light-0.3.1 failed during the configure step. The exception was: exit: ExitFailure 1 readline-1.0.1.0 failed during the configure step. The exception was: exit: ExitFailure 1

As one can see, it is much more difficult to use than R installation tools, or MikTeX installation tools. If cabal is so difficult, why use it? I am sure that I have done something very stupid mistake, but believe me, a lot of people is trying to use cabal and failing. I am not sure that it is a good idea to distribute libraries using cabal. However, this is irrelevant, because I am sure that creating a package with cabal is well beyond my powers. It is much easier to write a complete JAPI library, than packaging it in cabal.

Looking for the perfect gift? Give the gift of Flickr! _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 2009-11-09 12:39, Duncan Coutts wrote:

You'll be glad to know this is addressed in Cabal-1.8, though not in a fully automatic way. The problem with sharing automatically is knowing when it is safe to do so and when it is not. Each component that shares a source file can use different compiler options, cpp flags, and include dirs (and perhaps other stuff that we cannot easily track). Also, when you link it into a library you actually compile it differently than when you compile it into an executable (the -package-name flag is different).

So what we've done is to let executables depend on libraries. That makes the sharing explicit. At some point I also want to add support for private libs which would make this feature useful in more cases.

I was hoping that I could make use of this feature now: $ cabal --version cabal-install version 0.7.5 using version 1.8.0.2 of the Cabal library However, when I try to use it I get the following error: cabal: internal error: could not construct a valid install plan. The proposed (invalid) plan contained the following problems: The following packages are involved in a dependency cycle ... The relevant tests in the Cabal source tree also fail for me: PackageTests/BuildDeps/InternalLibrary[123] Is this feature supposed to work now, or has it been postponed? -- /NAD

Hello Gregory and Philippos Gregory, methinks you are a unix user as "Cabal" gives you a carefree existence (the scare quotes do highlight that it's not poor Cabal's fault). Philippos, the problems you are having aren't which cabal per-se but Haskell libraries that bind C libraries. On Windows I strongly recommend you install Cygwin, outside of the Microsoft toolchain (Visual Studio, C# etc.) any serious development on Windows really is troublesome without it, some development still is but that's another story. Installing Cygwin will pull in a huge amount of code first time round but after that it it manageable. Once you have Cygwin – here's how to install the pcre and readline bindings. Re-run the cygwin installer. For pcre you will need Devel/pcre and Libs/libpcre. For readline you will need Devel/readline and Lib/libreadlineN – I have both libreadline5 and libreadline6 installed, so clearly they can coexist. To build the Haskell bindings you want to be running Cygwin naturally. I'd make a directory in /usr/local tagged to the version of GHC I'm using eg Haskell_ghc_6_10_3 and copy the tar.gz's there (having a directory for a particular GHC version makes it easier to track which packages you are depending upon across GHC updates). Untar the packages with tar (some Windows archivers don't handle Unixed archives well)

tar xvfz readline-1.0.1.0.tar.gz tar xvfz pcre-0.3.1.tar.gz

At this point I'd edit the *.cabal files in each component – this is not 'the done thing', but both libraries need extra flags and as I have to compile them rarely I tend to forget the format (which appears to be Windows style full paths even though you are running Cygwin). Append this to the end of readline.cabal extra-lib-dirs: C:\cygwin\lib include-dirs: C:\cygwin\usr\include\readline C:\cygwin\usr\include Append this to the end of pcre-light.cabal extra-lib-dirs: C:\cygwin\lib include-dirs: C:\cygwin\usr\include Provide you have cygwin at the root of C: (which is very wise!), you should be able to build with the usual runhaskell Setup.lhs { configure | build | install | hadock } Best wishes Stephen

2009/11/9 Duncan Coutts :

That should work, and probably the recommendation should be for cygwin users to edit their cabal config to at add C:\cygwin\lib and C:\cygwin \usr\include as standard.

Hi Duncan That would definitely be the best idea, but where does the cabal config live? I have the cabal that ships with GHC-6.10.3 and can't find anything: cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library By the way, this one should be unnecessary, it was a legacy of me hacking all sorts of things to get readline installed: --extra-include-dirs=C:\cygwin\usr\include\readline Best wishes Stephen