May 2006 - cabal-devel

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 24 May '06

24 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 23 May '06

23 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 16 May '06

16 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

[shelarcy] Re: Cabal-Install doesn't work well on Windows.
by Isaac Jones 11 May '06

11 May '06

Would anyone care to try to get cabal-install going on windows? Or should we see about getting it going correctly in Unix first? peace, isaac

2 1

[patch] Workaround for ar and ld for Windows cmdline length restriction
by Esa Ilari Vuokko 10 May '06

10 May '06

Hi I have prepared a patch that works around Windows 32k command line length restriction when invoking ar and ld, this makes using ghc's split-objs possible in practice. Tue May 9 04:15:32 FLE Daylight Time 2006 Esa Ilari Vuokko <ei(a)vuokko.info> * Workaround for ar and ld for Windows cmdline length restriction There is no guarantee that algorithm works, ideally I should cut the lines at 32k, but instead I just call ar/ld for each one hundred files. Ld's case is a bit more complicated, with temp files. Algorithms aren't perfect, but I think they fit practically all packages out there (who has path to object file longer than 320+ characters, and hundred more?) Better solution would be to use ar's and ld's @file-functionality, but this isn't available in mingw's stable (or whatever) binutils yet, and of course builds for 6.4.x series will never have them, so it'd need ar/ld version checking which isn't totally trivial to add. Best regards, --Esa PS. Please CC me on replies as I am not subscribed. PSS. It seems to me that indentation in source has both tabs and spaces. That feels risky.

2 1

Re: Cabal-Install doesn't work well on Windows.
by shelarcy 10 May '06

10 May '06

Hello. On Thu, 04 May 2006 09:31:35 +0900, Isaac Jones <ijones(a)syntaxpolice.org> wrote: > I'm sorry I didn't reply earlier. We're scrapping that version of > cabal-install and replacing it with a better version that can download > packages from the internet. I'd certainly be happy to hear any > reports of how this works on windows. I don't know if it works at > all, and so any help would be great. Windows (mingw) version of GHC has no System.Posix.Signals functions and Types. System.Posix.Signals module exist, but no definition now. Because Windows' native posix support is very very poor, so signal support is also poor. Cause of these reason. I can't build cabal-install on Windows Enviorment. runhaskell Setup.lhs build notice these errors; ----- ../Network/Hackage/CabalInstall/Install.hs:107:39 Not in scope: `installHandler' ../Network/Hackage/CabalInstall/Install.hs:107:54 Not in scope: `keyboardSignal' ../Network/Hackage/CabalInstall/Install.hs:107:70 Not in scope: data constructor `Catch' ../Network/Hackage/CabalInstall/Install.hs:109:25 Not in scope: `installHandler' ../Network/Hackage/CabalInstall/Install.hs:109:40 Not in scope: `keyboardSignal' ---- Does anyone have plan to support cabakl-install on Windows? Or does anyone know that how to solove these problems? -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/

1 0

darcs patch: Change calls to 'make' into '$(MAKE)'
by Duncan Coutts 03 May '06

03 May '06

Tue May 2 18:46:30 BST 2006 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Change calls to 'make' into '$(MAKE)' This is the portable thing to do and fixes things on FreeBSD where make/=gmake

1 0