- cabal-devel - Haskell.org

Re: Cabal vs base
by Isaac Jones 10 Aug '06

10 Aug '06

Hey Neil. FYI, we now have a cabal-devel mailing list also for those interested in getting involved in cabal development. This mailing list is still appropriate for user questions or what-have-you, and I'm sure most of us stil read it :) "Neil Mitchell" <ndmitchell(a)gmail.com> writes: > I'm interested in using Cabal to build the base library, just like any > other library. Does this have any chance of working? How much work > would it take? I thought this already was happening? At least in GHC, I see libraries/base/base.cabal. > At the moment the libraries build script has broken on Windows loads > of times, and if Cabal was used it would be nicer, less code, and more > cross platform. Especially once we get cabal-install working to analyze the dependencies. > I'd also like to compile libraries for Hat, Yhc and Catch, and if I > can reuse cabal to do this that would be great. Please do! > If this work was done, would it be possible to reduce the > installation script for the full haskell.org libraries to get > library, cabal config, cabal build, cabal install? With the new cabal-install, you could possibly do: cd ghc/libraries cabal-install */*.cabal (assuming you already have cabal and stuff) > So just a general question about what needs doing, I don't think I understand you completely, so please let me know a bit more detail. Cabal is already used for building the libraries, at least for hugs, and I think for ghc, but perhaps not. Tweaking the ghc makefiles is probably necessary if that's what you want to do. > who is capable of doing it, and what I can do to get it working. YOU are capable of helping out w/ cabal-install and adding Hat & yhc support to cabal :) Paolo and Duncan are leadng the cabal-install effort. peace, isaac

3 2

darcs patch: Add liftField and maybeField to ParseUti... (and 1 more)
by Bertram Felgenhauer 02 Aug '06

02 Aug '06

The following two patches add the possibility to install hidden packages. The first one adds functionality to convert between StanzaFields of different types and uses that to simplify the parsing and pretty printing code for package descriptions. The patch should not change the behaviour in any way. The second patch is quite simple and just adds a flag. It would be much more involved without the first patch. What do you think? regards, Bertram Sun Jul 16 19:26:06 CEST 2006 Bertram Felgenhauer <int-e(a)gmx.de> * Add liftField and maybeField to ParseUtils and use them to simplify PackageDescription. This gets rid of the special handling of 'exposed-modules' and simplifies some pretty printing and parsing code. It'll make adding new library fields much easier. Sun Jul 16 19:35:08 CEST 2006 Bertram Felgenhauer <int-e(a)gmx.de> * Add 'exposed' library field to allow installing hidden packages.

4 8

Cabal package name patch
by Bertram Felgenhauer 01 Aug '06

01 Aug '06

Hi, Simon's recent changes to the package system have the effect that cabal-built packages cannot be used. Example error (from lambdabot, using fps that was previously built using cabal): scripts/BotPP.hs:20:0: Failed to load interface for `Data.ByteString.Char8': Bad interface file: /opt/ghc/lib/fps-0.7/ghc-6.5/Data/ByteString/Char8.hi Something is amiss; requested module fps-0.7:Data.ByteString.Char8 differs from name found in the interface file fps:Data.ByteString.Char8 The attached patch fixes this in Cabal by passing the full package name (including version) to the -package-name option. I expect that it breaks on older ghc versions, and thus should not be applied to the official darcs repository. But I hope it's still useful for someone while the underlying issue is resolved. (Maybe ghc shouldn't be unhappy about this in the first place?) regards, Bertram

4 3

needing to know install paths
by Duncan Coutts 01 Aug '06

01 Aug '06

Hi Cabal hackers, For c2hs we've run into a problem. See the thread about c2hs on window over on the haskell list. c2hs wants to install a data file (actually a .hs source file) and wants to know where it's been installed so that c2hs --copy-library can find and copy said file. So how do we do this? At the moment c2hs's Setup.hs calls a postInst script which installs a wrapper script (much like all the little ghc wrapper scripts which specifies the path where things can be found). Of course this doesn't work on Windows. I recall some talk about making this sort of thing easier? Where did we get with that? Duncan

3 5

[Paolo Martini] patches and questions
by Isaac Jones 28 Jul '06

28 Jul '06

Here's paolo's patch to start cleaning up cabal-get. Paolo, yeah, the put program is cabal-server-install. Can we start to use the mailing list more effectively? I really would like to get more people involved, and that can't happen if everything always goes through me :) peace, isaac

1 0

makefile patch for PATH
by Isaac Jones 26 Jul '06

26 Jul '06

Does anyone have objections to this? peace, isaac

2 1

Re: new cabal-get working for paolo
by Isaac Jones 25 Jul '06

25 Jul '06

Hey guys, let's use the mailing list :) Paolo, have you pushed this? Or sent it to cabal-devel? Great work. So what Paolo is saying is that the simple versin of cabal-get is ready, we just have to get the new very-simple version of cabal-put working and installed on hackage. There are pleanty of tweaks to do, though they may not be reflected in the ticket system. Alson, if you want to hack, please grab the latest cabal sources and see what we've done. Look at lately-modified tickets on the wiki to get some context. peace, isaac Paolo Martini <paolo(a)nemail.it> writes: > Hello! > > Let the log there speak for itself. > > $ cabal-install -c etc-cabal-install/ install helloWorld2 > configure: searching for ghc in path. > configure: found ghc at /usr/local/bin/ghc > "/usr/local/bin/ghc" --version >tmp839 > configure: looking for package tool: ghc-pkg near compiler in /usr/ > local/bin/ghc > configure: found package tool in /usr/local/bin/ghc-pkg > Using config dir: etc-cabal-install/ > configure: Reading installed packages... > "/usr/local/bin/ghc-pkg" --global list >tmp839 > Downloading 'helloWorld2-1.1' > Building 'helloWorld2-1.1' > Configuring... > Executing: '/usr/local/bin/runhaskell Setup.lhs configure' > Setup.lhs: Warning: No license-file field. > Configuring helloWorld2-1.1... > configure: Dependency base-any: using base-1.0 > configure: Using install prefix: /usr/local > configure: Binaries installed in: /usr/local/bin > configure: Libraries installed in: /usr/local/lib/helloWorld2-1.1/ > ghc-6.5.20060608 > configure: Private binaries installed in: /usr/local/libexec > configure: Data files installed in: /usr/local/share/helloWorld2-1.1 > configure: Using compiler: /usr/local/bin/ghc > configure: Compiler flavor: GHC > configure: Compiler version: 6.5.20060608 > configure: Using package tool: /usr/local/bin/ghc-pkg > configure: Using ar found on system at: /usr/bin/ar > configure: No haddock found > configure: No pfesetup found > configure: Using ranlib found on system at: /usr/bin/ranlib > configure: Using runghc found on system at: /usr/local/bin/runghc > configure: No runhugs found > configure: Using happy: /usr/local/bin/happy > configure: Using alex: /usr/local/bin/alex > configure: Using hsc2hs: /usr/local/bin/hsc2hs > configure: No c2hs found > configure: No cpphs found > configure: No greencard found > Building... > Executing: '/usr/local/bin/runhaskell Setup.lhs build' > Preprocessing executables for helloWorld2-1.1... > Building helloWorld2-1.1... > Chasing modules from: Hello.hs > [1 of 1] Compiling Main ( Hello.hs, dist/build/hello- > haskell-world/hello-haskell-world-tmp/Main.o ) > Linking dist/build/hello-haskell-world/hello-haskell-world ... > Installing... > Executing: '/usr/local/bin/runhaskell Setup.lhs install' > Installing: /usr/local/lib/helloWorld2-1.1/ghc-6.5.20060608 & /usr/ > local/bin helloWorld2-1.1... > Done. > > $ hello-haskell-world > Hello, Haskell World! > > ...it was an easy fix the one of the extensions, Isaac! > > I am getting the `put' program now. > > - Paolo

1 0

[Henning Thielemann] Re: Cabal: Improve Haddock support
by Isaac Jones 19 Jul '06

19 Jul '06

I might get a chance to look at this tonight :) Anyone else is welcome to volunteer. peace, isaac

2 2

[Fwd: Cabal and dependencies (Moved from Haskell-Cafe: Haskore dependency trouble)]
by Duncan Coutts 14 Jul '06

14 Jul '06

Oops, I accidentally discarded this email in some overzealous moderating. -------- Forwarded Message -------- > From: Henning Thielemann <lemming(a)henning-thielemann.de> > To: Bulat Ziganshin <bulat.ziganshin(a)gmail.com> > Cc: cabal-devel(a)haskell.org > Subject: Cabal and dependencies (Moved from Haskell-Cafe: Haskore > dependency trouble) > Date: Wed, 12 Jul 2006 14:34:40 +0200 (CEST) > > On Wed, 12 Jul 2006, Bulat Ziganshin wrote: > > > Wednesday, July 12, 2006, 1:23:53 PM, you wrote: > > > > > I would like to tell Cabal which modules are required and which are > > > supported, or recommended, but not needed. I could split Haskore into > > > several packages, but then again, installation of Haskore and its > > > sub-packages becomes uncomfortable and the Haddock documentation has no > > > longer a common table of contents. I tried to write custom Setup code for > > > finding out which parts of Haskore cannot be installed due to unsatisfied > > > dependencies, but this is more complicated than I hoped. > > > > such feature was already requested by Robert Dockins <robdockins(a)fastmail.fm> > > in libraries list at June 8. He wrote: > > > > "This brings up a feature I have sometimes wanted from Cabal. I'd > > like to be able to say the following: "Cabal, find and use package X > > if it exists. Furthermore, when CPPing source code, set a #define > > HAS_PACKAGE_X so I can do conditional compilation based on the (non-) > > avaliablility of package X". Is this possible? Difficult? It seems > > like a nice way to handle a number of problems, including platform- > > dependencies (as here) and optional features with external > > dependencies." > > > > you can add your voice to the peoples requesting this feature (i need > > it, too) > > I guess our goals are similar, however I prefer not using a preprocessor. > So in case of an unsatisfied package I like simply some modules to be > ignored by Cabal. I tried to solve this by myself, by splitting up the > monumental Haskore.cabal file into sub-files which depend on each other. > However, Cabal cannot handle multiple cabal files. It would have to find > out the right order of compilation (I already implemented that > successfully with the FGL), but then it had to compile within the same > build directory or at least make a monolithic Haddock documentation.

1 0

difficulty building executable
by Evan Martin 13 Jul '06

13 Jul '06

Hi all, Sorry if this isn't the right list for cabal questions, but I figure that if I couldn't figure this out from reading the docs, you'd at least like to be aware of the doc bug. I have a library that seems to build ok, and along with it I have a "demo" executable that uses the module. However, that demo executable doesn't build: it seems ghc tries to chase a dependency from the executable back into the library source instead of using the built library. Here's the cabal file: name: DBus version: 0.1 license: BSD3 license-file: LICENSE copyright: Copyright (C) 2006 Evan Martin <martine(a)danga.com> author: Evan Martin <martine(a)danga.com> homepage: http://neugierig.org/software/hdbus synopsis: DBus bindings description: Bindings for the DBus API. For details on DBus, see the DBus wiki at: http://www.freedesktop.org/wiki/Software/DBus build-depends: base extensions: ForeignFunctionInterface, OverlappingInstances, ExistentialQuantification exposed-modules: DBus, DBus.Message, DBus.Connection other-modules: DBus.Error, DBus.Internal, DBus.Shared executable: demo main-is: Demo.hs other-modules: DBus Here's the output of build --verbose: Reading parameters from /home/martine/projects/haskell/hdbus/DBus.buildinfo Preprocessing library DBus-0.1... /usr/bin/hsc2hs -D__GLASGOW_HASKELL__=604 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -o DBus.hs DBus.hsc /usr/bin/hsc2hs -D__GLASGOW_HASKELL__=604 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -o DBus/Message.hs DBus/Message.hsc /usr/bin/hsc2hs -D__GLASGOW_HASKELL__=604 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -o DBus/Connection.hs DBus/Connection.hsc /usr/bin/hsc2hs -D__GLASGOW_HASKELL__=604 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -o DBus/Error.hs DBus/Error.hsc /usr/bin/hsc2hs -D__GLASGOW_HASKELL__=604 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -o DBus/Internal.hs DBus/Internal.hsc /usr/bin/hsc2hs -D__GLASGOW_HASKELL__=604 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -o DBus/Shared.hs DBus/Shared.hsc Preprocessing executables for DBus-0.1... Building DBus-0.1... /usr/bin/ghc -optc-I/usr/include/dbus-1.0 -optc-I/usr/lib/dbus-1.0/include -package-name DBus -odir dist/build -hidir dist/build -hide-all-packages --make -i -i. -ffi -fallow-overlapping-instances -fglasgow-exts -package base-1.0 DBus DBus.Message DBus.Connection DBus.Error DBus.Internal DBus.Shared Chasing modules from: DBus,DBus.Message,DBus.Connection,DBus.Error,DBus.Internal,DBus.Shared Compiling DBus.Internal ( ./DBus/Internal.hs, dist/build/DBus/Internal.o ) Compiling DBus.Shared ( ./DBus/Shared.hs, dist/build/DBus/Shared.o ) Compiling DBus.Error ( ./DBus/Error.hs, dist/build/DBus/Error.o ) Compiling DBus ( DBus.hs, dist/build/DBus.o ) Compiling DBus.Message ( ./DBus/Message.hs, dist/build/DBus/Message.o ) Compiling DBus.Connection ( ./DBus/Connection.hs, dist/build/DBus/Connection.o ) /usr/bin/ar q dist/build/libHSDBus-0.1.a dist/build/DBus.o dist/build/DBus/Message.o dist/build/DBus/Connection.o dist/build/DBus/Error.o dist/build/DBus/Internal.o dist/build/DBus/Shared.o /usr/bin/ar: creating dist/build/libHSDBus-0.1.a /usr/bin/ld -r -x -o dist/build/HSDBus-0.1.o dist/build/DBus.o dist/build/DBus/Message.o dist/build/DBus/Connection.o dist/build/DBus/Error.o dist/build/DBus/Internal.o dist/build/DBus/Shared.o /usr/bin/ghc -odir dist/build/demo/demo-tmp -hidir dist/build/demo/demo-tmp -o dist/build/demo/demo -hide-all-packages --make -i -i. -package base-1.0 Demo.hs Chasing modules from: Demo.hs Compiling DBus.Internal ( ./DBus/Internal.hs, dist/build/demo/demo-tmp/DBus/Internal.o ) Internal.hsc:21:8: parse error on input `import' That "import" it's failing on is because Internal.hsc depends on FFI. However, Demo.hs doesn't itself refer to Internal anywhere: instead (I think?) it ought to use the Internal.o that was built in the library. (As you can see in the log, Internal.o built just fine within the library.) Please let me know if you need any more information. I'll post a quick tutorial on the simplest possible build that uses pkg-config (I saw the earlier thread where it was suggested to support it directly -- that'd help me too) once I get this working.

1 0