- cabal-devel - Haskell.org

difficulty building executable
by Evan Martin 14 Jul '06

14 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

[Jeremy Shaw] [Debian-haskell] First pass at -prof support in dh_haskell
by Isaac Jones 11 Jul '06

11 Jul '06

FYI. dh_haskell is a tool for creating debian packages from cabal packages. Jeremy is working on adding support for building separate profiling libraries. peace, isaac

1 0

new cabal-get developments
by Isaac Jones 08 Jul '06

08 Jul '06

Audrey Teng and I hacked on cabal-get a few weeks ago. Some details are here: http://hackage.haskell.org/trac/hackage/ticket/62 Basically, Audrey was able to talk me out of my "smart server, dumb clients" stance. HackageDB is now just a directory tree with an index file. She also implemented better local install for mutiple cabal packages with cabal-get. I haven't played with this much. The way it's going to work, at least for the short term, is that anyone w/ access to monk.haskell.org (aka darcs) will be able to run the 'put' program to add packages to hackage. Anyway, take a look at the code and tell me what you think. xerox is going to be working on it for his SoC project, as we started to outline here: http://hackage.haskell.org/trac/hackage/ticket/87 peace, isaac

1 0

darcs patch: Change flags passed to hsc2hs
by Duncan Coutts 04 Jul '06

04 Jul '06

I made this patch after noticing that John Goerzen's ldap-haskell package doesn't compile (with recent versions of OpenLDAP) because the hsc2hs call fails with a linking error. hsc2hs compiles and links a C program to generate the final .hs file. It turned out that the .c file was referencing not just constants from the ldap.h file but things which translated into linker symbols. So when it linked there were missing symbols. The solution is this case is to pass -L-lldap to hsc2hs. So this patch does that in the general case, all extra-libaries are passed to hsc2hs (prefixed with --lflag=-l). Tue Jul 4 01:19:26 BST 2006 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Change flags passed to hsc2hs The extra-libraries must be passed as -L-l${lib} or linking the C prog that hsc2hs generates may fail if any symbols are referenced. Also can't use cppOptions function since hsc2hs doesn't support -U. Need to do -U flags in ccOptions seperately. It's also arguable that we should pass all cc options and ld options using --cflag= and --lflag= . This is what the build system for Gtk2Hs does. Opinions? Duncan

2 1

Re: [Haskell] Re: Interfacing to OLE/COM: HaskellDirect the only game in town?
by shelarcy 25 May '06

25 May '06

On Wed, 24 May 2006 18:28:01 +0900, Simon Marlow <simonmarhaskell(a)gmail.com> wrote: > It has bitrotted to some extent. In Visual Haskell we use > HaskellDirect-generated interfaces with a lot of hacking by hand to make > it work, I don't believe we can re-generate the source files from IDL > any more. Hmm. Before I read this mail, I think you change only non-generated source files. So If I write better Setup.(l)hs file or, add H/Direct's ihc and apply different option file by file support, I can made newer cabalised version HDirect package - just replace source files. Anyway, I think that ihc - an IDL compiler for Haskell - support for Cabal is useful. So I send mail, this time. I already made initial that ... but if make buildable Haskell source file, I have to use different option one by one, like this; = lib/Makefile = WideString_IHC_OPTS += -fno-imports -fno-export-lists -fkeep-hresult -fout-pointers-are-not-refs PointerPrim_IHC_OPTS += -fkeep-hresult -fout-pointers-are-not-refs = comlib/Makefile = AutoPrim_IHC_OPTS += -fno-imports -fno-export-lists -fhs-to-c -fno-overload-variant -fout-pointers-are-not-refs -fsubtyped-interface-pointers ComPrim_IHC_OPTS += -fno-imports -fno-export-lists -fout-pointers-are-not-refs WideString_IHC_OPTS += -fno-imports -fno-export-lists -fkeep-hresult -fout-pointers-are-not-refs PointerPrim_IHC_OPTS += -fkeep-hresult -fout-pointers-are-not-refs StdTypes_IHC_OPTS += -fno-export-list -fno-gen-variant-instances -fout-pointers-are-not-refs --gen-headers SafeArray_IHC_OPTS += -fhs-to-c -fno-export-lists --gen-headers -fout-pointers-are-not-refs --gen-headers TypeLib_IHC_OPTS += -fno-export-list -fappend-interface-short-name -fno-overload-variant --gen-headers Connection_IHC_OPTS += -fappend-interface-short-name and I didn't support this feature yet. If you use atttached hdirect.cabal file, after applied cabal-ihc-support.patch for darcs repository, you can see compile error from generated file. Does anyone have good idea? -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/

1 0

pkg-config support
by Duncan Coutts 24 May '06

24 May '06

So here's a feature I was thinking of implementing but I'd just like to check that people think it is an appropriate thing to implement. pkg-config is a system that many C libraries now use for managing the C compiler flags needed to build programs that use those libraries. If you check on any recent Linux system you will find some version of pkg-config and if you run pkg-config --list-all you should see a sizable list of libraries. Haskell bindings libraries that use such C libs need to call pkg-config as part of their build system to work out what compiler flags to use (and just to check that a suitable version of the C lib is installed). Of course this is just one instance of a more general issue of where the flags needed to build a package are not constant and have to be discovered at configure time. Anyway, so the idea is that one could add easy support for pkg-config to Cabal. It'd use pkg-config to check that the appropriate version of the lib is installed and discover the cc-options and ld-options necessary to compile and link to that C lib. So my question is: would it be sensible to add this feature to Cabal, probably in the form of yet another field in the .cabal file or should we look at something more general? It'd be very convenient to be able to just say: pkg-config-depends: dbus-1 >= 0.60 On the other hand I can see that we should worry about an ever increasing list of fields in the .cabal file. As a comparison, with autoconf they have a (large) number of macros for common stuff which can then be extended by other packages that are installed. So if you install pkg-config then it installs some additional macros which do the pkg-config version checks and find the CFLAGS & LIBS etc. So of course it would be possible to implement this pkg-config stuff using hooks on a per-package basis. Though of course one would want to factor out that common code and put it in a library. Cabal would be the obvious library to put it in of course. So (to play devils advocate) if it'd probably go in Cabal either way, why would we want to make it harder to use by insisting that pkg-config features are accessed via Setup.lhs rather than a simple one line in the .cabal file. I don't know which is the best way. It comes back to the dilemma over how much goes into the declarative .cabal file and how much goes into opaque Haskell code in Setup.lhs. Duncan

2 2

version policies
by Isaac Jones 23 May '06

23 May '06

Heya, Would anyone like to write up some proposed versioning policies for cabal and packages that use cabal? The idea would be something along the lines of: 1.0.0 == release 1.1.1 == between releases (darcs version) 1.1.2 == release candidate for 1.2 1.1.3 == between releases (darcs version) 1.1.4 == release candidate for 1.2 1.2.0 == release that doesn't break compatibility w/ 1.0.0 1.2.1 == darcs 1.2.2 == release candidate for 1.4, or revision relesae 2.0.0 == major release, not necessarily backward compatible. This is just an example, but the way I see it, the numbering system is pretty much arbitrary, it would be nice if there were a standard / recommended way to do it, so that everyone doesn't have to invent their own, and so that users can expect some common patterns. If someone wants to do this, please start a wiki page on the hackage / cabal wiki. peace, isaac

1 0

File locations for cabal-install
by Alson Kemp 22 May '06

22 May '06

> A question for the group: > Where should cabal-install's various files go? > > Note: > None of the cabal-install files is dependent on a particular > version > of Cabal or GHC, so the files do not need to be stored in > versioned-directories (e.g. Cabal-1.1.5 or Cabal-1.1.5/ghc-6.4.2). > > Files: > server.list - one line config file with the Hackage server > location, > basically never modified; > package.list - the listing of packages available on the Hackage > server; > packages/ - the directory in which all of the downloaded packages > are stored. > > Options: > 1) Proper: /etc/server.list, > /var/local/lib/cabal-install/package.list, > /var/local/lib/cabal-install/packages/. A bit dogmatic and I'm not > sure how it maps onto non-*nix systems, but it's the Right Thing to > do > on *nix. > 2) Easy: everything goes in $lib-prefix/cabal-install. Isn't the > prettiest solution, but it's functional. Maps onto Windows well. > Users will never directly see or use these files, so > $lib-prefix/cabal-install. (GHC does this with its package.conf.) > 3) [other suggestions?] > > > I think that Isaac prefers Option 1 because it's the proper way to do > things; I prefer Option 2 because it's a pretty good solution even if > it isn't *nixy. > > Opinions? Arguments? Suggestions? > > - Alson

3 2

Welcome!
by Isaac Jones 15 May '06

15 May '06

Welcome to the cabal-devel mailing list! I'm very please to see so many folks signed up already. I'll just re-post the release announcement that Duncan made below. As Duncan mentioned, he'll be the release manager for Cabal, so hopefully I'll have a bit more time for hacking. All your donations will still go to me, though ;) peace, isaac === Cabal 1.1.4 release === Cabal-1.1.4, the version shipped with GHC 6.4.2 is now available to download as a separate tarball: http://haskell.org/cabal/download.html http://haskell.org/cabal/release/cabal-1.1.4/cabal-1.1.4.tar.gz Note that there was some confusion over the version number. If you got a darcs development snapshot in the last few months it will likely have been marked 1.1.4, however it should have been marked 1.1.5. 1.1.4 is the version shipped with GHC 6.4.2 and available as the tarball above. The current darcs development version is 1.1.5. We'll try to avoid such confusion in the future. === New Cabal-devel mailing list === There is also a new cabal-devel(a)haskell.org mailing list for Cabal development discussion including patch review. This is where patches sent via "darcs send" will end up. We welcome anyone to join the list and help discuss ongoing Cabal development or just to keep an eye on what's going in. Sign up here: http://haskell.org/mailman/listinfo/cabal-devel We'd also like to take the opportunity to invite people to get involved in Cabal development, either new features or squashing annoying bugs. It's as simple as: darcs get --partial http://darcs.haskell.org/packages/Cabal # write patch darcs record darcs send People who already commit directly via darcs push are welcome to continue to do so for patches they consider obvious. If they would like some review and feedback then they are welcome to "darcs send" instead and discuss the patch on the mailing list before committing. Note that this new list is not intended to take discussions of Cabal away from the libraries list. Issues affecting users should still go to libraries(a)haskell.org. The intention is to have more discussion and review of Cabal development. Duncan (who is wearing his new Cabal release manager's hat)

3 5

System.Directory.findExecutable and ghc's ld in Windows
by Esa Ilari Vuokko 15 May '06

15 May '06

Hi! (please CC me as I am not subscribed) Happens on Cabal darcs head and Windows with ghc. In Distribution.Simple.GHC.build we try to invoke ld. In Windows this file is found by deduction from ghc.exe path. (foo\bin\ghc.exe -> foo\gcc-lib\ld.exe). When this absolute (rooted) path is passed on to rawSystem*, it gets search through PATH environment-variable in System.Directory.findExecutable (or the version in Compat.) System.Directory.findExecutable went through a rewrite for Windows between 6.4 series and 6.5 - it now uses Windows API function SearcPath which passes absolute paths straight throuhg, at least on my system (Windows XP). In the end, because 6.4.2 doesn't let absolute paths through, we need a fix. What is the right way here? Assume ghc 6.4.3 and get fix merged (see diff [1]); Add extra check for absolute path and file existence on findExecutable (and propagate this fix to base); Or inline the rawSystem* (as needed) in GHC.hs under correct preprocessor if's? Oh, yeah, we can also say that ghci libs just don't work under 6.4.x in Windows ;) Please advice. [1] http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/System/Dir… Best regards, --Esa

2 1