[Haskell-cafe] Cabal
Philippos Apolinarius
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!
Gregory Crosswhite
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
> Looking for the perfect gift? Give the gift of Flickr!
> _______________________________________________
> Haskell-Cafe mailing list
> Haskel...@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
Gregory Crosswhite
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
Duncan Coutts
> 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.
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.
Duncan
Stephen Tetley
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
Duncan Coutts
> 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
Hmm, I get a slightly different error that indicates somewhat better the
actual cause. It says that it cannot find sh.exe.
The real problem here is that those two packages use ./configure
scripts. Those rarely work under windows. For starters you need msys and
mingw installed. Even once you've done that however we get the problem
of missing C libs.
Duncan
Duncan Coutts
> 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).
Does it not work to say:
cabal install readline \
--extra-lib-dirs=C:\cygwin\lib \
--extra-include-dirs=C:\cygwin\usr\include \
--extra-include-dirs=C:\cygwin\usr\include\readline
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.
Duncan
Stephen Tetley
>
> 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
Duncan Coutts
> D:\ghc\ghcapi>cabal install mkcabal
Note that as of cabal-install-0.8, the "mkcabal" functionality is
integrated as "cabal init" (thanks to Brent Yorgey). This does not
depend on less portable packages like pcre and readline (meaning it will
work on Windows).
> Resolving dependencies...
> Downloading pcre-light-0.3.1...
> Configuring pcre-light-0.3.1...
There's no reason pcre-light needs a configure script. It should be
removed. (It's also not used consistently, the Setup.hs is for a
different build-type than the one specified in the .cabal file).
> 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 of Cabal-1.8 the error is reported as:
cabal: The package has a './configure' script. This requires a
Unix compatibility toolchain such as MinGW+MSYS or Cygwin.
Duncan
Duncan Coutts
> 2009/11/9 Duncan Coutts <duncan...@googlemail.com>:
>
> >
> > 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?
If you were running the current version then "cabal --help" would say.
To upgrade run:
cabal install cabal-install
Otherwise, it's somewhere like
C:\Documents and Settings\$user\Application Data\cabal\config
though on some systems (vista perhaps?) I think it's under the user's
roaming profile directory.
Duncan
Nils Anders Danielsson
> 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
Duncan Coutts
> 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:
So there's two bugs.
One is that cabal-install doesn't know about this new stuff. Stephen
Blackheath has a patch for this but it's not yet been reviewed and
integrated.
The other is that the feature currently fails with ghc-6.12 but we
didn't notice in time to fix it before the release.
> Is this feature supposed to work now, or has it been postponed?
It works with 6.10 if you're not using cabal-install.
Both issues will be addressed in future releases in the new stable
series.
Duncan