August 2005 - Libraries

Getting Cabal 1.1.1 working on Windows 98
by Toby Allsopp 09 Aug '05

09 Aug '05

The version of Cabal that comes with GHC (6.4 and 6.4.1) doesn't run on Windows 98 because of a missing SHGetFolderPathA function, so I thought I'd try to compile version 1.1.1 myself. I see that some work has been done in CVS for this problem, but I thought I'd post the changes I had to make to get 1.1.1 to work incase this is helpful to other people or to getting it fixed propoerly. I'm using MinGW 4.1, MSYS 1.0.10 and MSYS Developer Tool Kit 1.0.1. I've attached a patch against version 1.1.1. First, I tried compiling setup without any changes: $ make HCBASE=/c/ghc/ghc-6.4.1/bin/ setup ... Compiling Main ( Setup.lhs, dist/tmp/Main.o ) Linking ... dist/tmp/Distribution/Simple/Configure.o(.text+0xe41):fake: undefined reference to `SHGetFolderPath@20' make: *** [setup] Error 1 Ok, this seems to be because we need to pick either the A or W version. I'm not sure how to get this to happen automatically, but I guess we want the A version: $ diff ../cabal-1.1.1.orig/Distribution/Simple/Configure.hs Distribution/Simple /Configure.hs 256c256 < foreign import stdcall unsafe "SHGetFolderPath" --- > foreign import stdcall unsafe "SHGetFolderPathA" Now, I try again: $ make HCBASE=/c/ghc/ghc-6.4.1/bin/ setup ... Skipping Main ( Setup.lhs, dist/tmp/Main.o ) Linking ... Yay, it compiled! Now I try to run it: $ make HCBASE=/c/ghc/ghc-6.4.1/bin/ config "The SETUP.EXE file is linked to missing export SHELL32.DLL:SHGetFolderPathA" (The message is GUI dialog box.) Ah, this is because SHGetFolderPathA is not in SHELL32.DLL on Windows 98, but in SHFOLDER.DLL. It is also in SHFOLDER.DLL on later versions, so this change should be safe: $ diff ../cabal-1.1.1.orig/GNUmakefile GNUmakefile 4c4 < GHCFLAGS= --make -Wall -fno-warn-unused-matches -cpp --- > GHCFLAGS= --make -Wall -fno-warn-unused-matches -cpp -lshfolder Try again: $ make HCBASE=/c/ghc/ghc-6.4.1/bin/ config ... Skipping Main ( Setup.lhs, dist/tmp/Main.o ) Linking ... ./setup configure --ghc --prefix=/usr/local Configuring Cabal-1.1.1... configure: Using install prefix: C:/MSYS/1.0/local configure: Using compiler: c:\GHC\GHC-6.4.1\BIN\ghc.exe configure: Compiler flavor: GHC configure: Compiler version: 6.4.1 configure: Using package tool: c:\GHC\GHC-6.4.1\BIN\ghc-pkg.exe configure: No haddock found configure: No happy found configure: No alex found configure: Using hsc2hs: c:\GHC\GHC-6.4.1\BIN\hsc2hs.exe configure: No c2hs found configure: No cpphs found configure: No greencard found configure: Dependency base-any: using base-1.0 configure: Dependency util-any: using util-1.0 Yay! Now to install it: $ make HCBASE=/c/ghc/ghc-6.4.1/bin/ install ... Installing: C:/MSYS/1.0/local\Haskell\Cabal-1.1.1\ghc-6.4.1 & C:/MSYS/1.0/local\Cabal-1.1.1\bin Cabal-1.1.1... Registering Cabal-1.1.1... Ok, it all seems fine. Now to try to use it: $ cd tests/HSQL $ runghc Setup.lhs configure ghc.exe: unable to load package `Cabal-1.1.1' <interactive>: C:/MSYS/1.0/local\Haskell\Cabal-1.1.1\ghc-6.4.1/HSCabal-1.1.1.o: unknown symbol `_SHGetFolderPathA' Bummer. We need to link with SHFOLDER.DLL. So, we change Cabal's cabal file (similarly to the comment that was in CVS recently): $ cd ../.. $ diff -u ../cabal-1.1.1.orig/Cabal.cabal Cabal.cabal --- ../cabal-1.1.1.orig/Cabal.cabal Sat Aug 6 11:50:00 2005 +++ Cabal.cabal Sat Aug 6 12:17:46 2005 @@ -48,6 +48,7 @@ Distribution.Compat.Exception, Distribution.Compat.RawSystem Extensions: CPP +Extra-Libraries: shfolder executable: cabal-setup main-is: DefaultSetup.lhs Then, install again and try the test again: $ make HCBASE=/c/ghc/ghc-6.4.1/bin/ install ... Registering Cabal-1.1.1... $ cd tests/HSQL/ $ runghc Setup.lhs configure -=-= Cabal executing: ./configure =-=- Bad command or file name Configure Succeeded. Triple yay! Using this version I have successfully installed the real HSQL. How, it seems wrong to have to specify the A or W version explicitly because there is a #define for it that depends on whther UNICODE is defined. I don't know why that's not being picked up (it's in shldobj.h and I see that that's been specified in CVS, but adding it makes no difference for me.) The patch follows:

4 6

RE: datadir (was: RE: new package description fields, sdist, andpreprocessors)
by Simon Marlow 09 Aug '05

09 Aug '05

On 09 August 2005 09:56, Bernard Pope wrote: > On Tue, 2005-08-09 at 09:36 +0100, Simon Marlow wrote: > >> The problem, of course, is how to get the value of $datadir to the >> program if it is configurable. I suggested a CPP symbol, but that is >> far from ideal (we don't do it this way in fptools projects any more >> for various reasons). Another option is to have the Setup script >> generate a file containing the declarations: >> >> -- paths.h >> prefix="/usr/local" >> bindir="bin" -- or absolute >> libdir="lib/foo-1.0/ghc-6.4" >> datadir="share/foo-1.0" >> >> which you can then #include into Haskell source. Another >> alternative, if you want to avoid CPP, is to have Setup generate a >> complete Haskell module with these declarations, but then you have >> to somehow choose an appropriate module name that doesn't clash. >> >> paths.h gets my vote. Anyone have any better ideas? > > What if, say, you have some C code in your package that also wants to > know the values of these paths? There's no single solution that works for all languages. The good news is that prefix/bindir/libdir/datadir would be available in the LocalBuildInfo, so you would be able to implement any scheme you like using the postConf hook. And maybe we could refer to these values in the .cabal file, so you could write extra-cc-options: -Dprefix=$prefix (probably some quoting required somewhere, but you get the idea). Cheers, Simon

1 0

datadir (was: RE: new package description fields, sdist, and preprocessors)
by Simon Marlow 09 Aug '05

09 Aug '05

On 09 August 2005 02:59, Isaac Jones wrote: > Ross Paterson <ross(a)soi.city.ac.uk> writes: >> On Wed, Aug 03, 2005 at 07:27:01PM -0500, Brian Smith wrote: >>> On 8/3/05, Ross Paterson <ross(a)soi.city.ac.uk> wrote: >>>> 3) New field data-files, a list of files to be copied to a place >>>> where an executable can find them (e.g. template-hsc.h for >>>> hsc2hs): Hugs: the directory containing the Main module >>>> GHC/Windows: the directory containing the executable >>>> GHC/Unix: /usr/local/share/<exename> >>>> plus a new function in System.Directory to return the name of >>>> this directory. That would address Dimitry's requirements in >>> >>> How about allowing directories too, which would be copied >>> recursively? >> >> No objection to that. > > This sounds good, except that I'm not sure that System.Directory is > the right place for this. It could also go in Distribution > somewhere, but either way may be fine. > > Also, if we do this, we should probably specify the manner in which > such a directory should be layed out so: > > 1) it doesn't get too cluttered > 2) different packages don't stomp on each-other's files and > 3) different versions of different packages can use the same > filenames. > > One stab at it (where dataFileDir :: FilePath) would be that your > datafiles should be in: > > System.Directory.dataFileDir > `joinFilePath` (packageName ++ "-" packageVersion) > > and this is where cabal will put it. This overlaps with my --datadir proposal. I think that datadir should be configurable at Setup-time, with sensible defaults as per Ross's mail above. The default should at least be specified relative to $prefix (eg. if $prefix is /usr, I don't want $datadir to be /usr/local/share/<pkg>). Also, if the data files are machine-dependent then they should really go in $libdir rather than $datadir. The problem, of course, is how to get the value of $datadir to the program if it is configurable. I suggested a CPP symbol, but that is far from ideal (we don't do it this way in fptools projects any more for various reasons). Another option is to have the Setup script generate a file containing the declarations: -- paths.h prefix="/usr/local" bindir="bin" -- or absolute libdir="lib/foo-1.0/ghc-6.4" datadir="share/foo-1.0" which you can then #include into Haskell source. Another alternative, if you want to avoid CPP, is to have Setup generate a complete Haskell module with these declarations, but then you have to somehow choose an appropriate module name that doesn't clash. paths.h gets my vote. Anyone have any better ideas? Cheers, Simon

3 3

package description fields
by Ross Paterson 09 Aug '05

09 Aug '05

Proposals: 1) New field extra-tmp-files, a list of extra files to be removed by setup clean, beyond those that can be deduced. 2) Rename other-files as extra-source-files for consistency and clarity. 3) New field data-files, a list of files to be copied to a place where an executable can find them (e.g. template-hsc.h for hsc2hs): Hugs: the directory containing the Main module GHC/Windows: the directory containing the executable GHC/Unix: /usr/local/share/<exename> plus a new function in System.Directory to return the name of this directory. That would address Dimitry's requirements in http://www.haskell.org/pipermail/haskell-cafe/2005-July/010886.html Dimitry has a more elaborate proposal: http://www.haskell.org/pipermail/libraries/2005-July/004146.html

4 5

on when to build ghci libs in cabal
by Isaac Jones 09 Aug '05

09 Aug '05

Henning Günther and Duncan Coutts / the Gentoo team have sent me a patch to move creation of ghci libs to the build phase rather than the register phase. It makes more sense there and should be somewhat better for debian and gentoo. Though Duncan points out that maybe some ppl want to build the ghci libs during register because it could save room in a binary distribution (like debian and rpm). Any opinions here? Also, I noticed the "FIXME" that mentions the -x flag is only supported on some platforms; what effect will this have on platforms that don't support it? Will they be broken during build? What about platforms where we know the ghci libs don't work, like MacOS; will this patch cause building to break? The patch adds a couple extra configure options, --enable-library-for-ghci / --disable-library-for-ghci. I'm sorta thinking of just having one option "--disable-interpreter-libs" or something to make this seem more generic, though at the moment, it still only makes sense for a combo compiler / interpreter build (that is, --ghc). I'll be happy to add this to the manual once we settle on a flag. Do we ever really need to disable it anyway? peace, isaac

4 4

RE: package description fields
by Simon Marlow 08 Aug '05

08 Aug '05

On 04 August 2005 08:24, Krasimir Angelov wrote: > I would like to propose more Unix like directory layout for Windows > i.e.: > > executables: %ProgramFiles%\<pkg-name>\bin > libraries: %ProgramFiles%\<pkg-name>\lib > data files: %ProgramFiles%\<pkg-name>\data > > The advantage is that if you have a lot of libraries and data files > then it is easier to find out the executable files. Happy, Alex and > Haddock already use layout like in the Ross's proposal but I found it > very inconvenient because usually I am building them together with > ghc. The problem is that when I do make install in the fptools > directory then ghc is installed in ${prefix}/bin but the above tools > are installed in ${prefix}. Usually then ${prefix} directory isn't > included in the PATH and this makes them inaccessible. I can move them > to ${prefix}/bin but then I have to move all other template files too. > It would be nice if we had more consistent directory layout. Your complaint here seems to be that the default layout of Happy, Alex and Haddock is different from that of GHC on Windows, which makes it harder to combine all these tools in a single package. As far as Cabal is concerned, I think the defaults are fine. However, I do think we should allow the default $bindir/$libdir/$datadir to be overridden (I know this has been discussed before). On Windows, an application often finds its files relative to the location of the executable, so the values of $bindir/$libdir/$datadir need to be passed to the program at build time, perhaps via CPP symbols. So, I suggest we have: --bindir=<dir> --libdir=<dir> --datadir=<dir> where the values of these would be directories relative to $prefix (or absolute? relative to $prefix seems nicer). And when processing with CPP, Cabal would pass -DBINDIR=<dir> -DLIBDIR=<dir> -DDATADIR=<dir>. Using this, Krasimir could configure Happy, Alex and Haddock to use a layout compatible with GHC, whereas the defaults would reamin as they are. Cheers, Simon

2 1

cabal release?
by Isaac Jones 08 Aug '05

08 Aug '05

I would like to make a Cabal release Real Soon Now, version 1.0.2. There are always more changes that would be good to get in, but we have to release sometime. This is just a minor release, and it's not being released with a compiler like the 1.0 release, so it doesn't need to be "perfect". We haven't exactly been releasing early and often, but in that spirit, let's get the many changes since 1.0 out into the wild. Here's a summary from the changelog: * Handles recursive modules for GHC 6.2 and GHC 6.4. * Added "setup test" command (Used with UserHook) * implemented handling of _stub.{c,h,o} files * Added support for profiling * Changed install prefix of libraries (pref/pkgname-version to prefix/pkgname-version/compname-version) * Added pattern guards as a language extension * Moved some functionality to Language.Haskell.Extension * Register / unregister .bat files for windows * Exposed more of the API * Added support for the hide-all-packages flag in GHC > 6.4 * Several bug fixes Oh, and though it's not a big change from Cabal's perspective, there are some changes that are necessary to get Hackage out the door. Does anyone know of any: - critical bugs that we shouldn't release without fixing - interface changes that are so horrible that we shouldn't release without fixing them I'm a bit concerned about the different release cycles that Cabal and the compilers will be following, but I think that if we are careful with version numbers we'll be OK :) peace, isaac

4 10

RE: Cabal should use the minimum version that satisfies thedependencies, not the maximum
by Simon Marlow 08 Aug '05

08 Aug '05

On 08 August 2005 07:45, Brian Smith wrote: > Let's say we have multiple versions of a package installed: > a-1.0 > a-1.0.1 > a-1.1 > a-2.0 > and that we have the following Build-Depends in a package description: > Build-Depends: a >= 1.0 > > Now, when I configure, Cabal will choose a-2.0 as the package to build > with. However, it makes more sense to choose a-1.0 by default instead. I don't agree, there is just as much potential for breakage with this choice, and it will cause problems if someone is trying to upgrade their system incrementally. If I have both a-1.0 and a-2.0 installed, I probably don't want any new dependencies on a-1.0, because I want to delete it at some point. > * Currently, if we change the program to require a feature that is in > a-2.0, but not in a-1.0, then the build will succeed for _us_, but it > will fail unexpectedly for someone else that has only a-1.0. However, > if Cabal instead chose the minimum version available, then, _our_ > build would fail, and we would know that we need to either remove the > dependency on the a-2.0 feature or increase the version specified in > Build-depends. Conversely, if the author builds with a-1.0, and the recipient builds with a-2.0 and version 2.0 is not backwards compatible, then the package will break. If the package depends on a-1.0 rather than a>=1.0, then it should say so. > * a-2.0 is not guarenteed to be 100% backwards-compatible with a-1.0. > Even a-1.0.1 is not guarenteed to be backwards-compatible. So, if the > original author was really testing with a-1.0, then we are more likely > to run into problems with a-2.0 (or even a-1.0.1) than a-1.0. This is true, but most people will not have multiple versions of a package installed. Furthermore, we'd like to discover problems early, and this just hides the bug in the dependency specification. Cheers, Simon

1 0

Cabal should use the minimum version that satisfies the dependencies, not the maximum
by Brian Smith 08 Aug '05

08 Aug '05

Let's say we have multiple versions of a package installed: a-1.0 a-1.0.1 a-1.1 a-2.0 and that we have the following Build-Depends in a package description: Build-Depends: a >= 1.0 Now, when I configure, Cabal will choose a-2.0 as the package to build with. However, it makes more sense to choose a-1.0 by default instead. * Currently, if we change the program to require a feature that is in a-2.0, but not in a-1.0, then the build will succeed for _us_, but it will fail unexpectedly for someone else that has only a-1.0. However, if Cabal instead chose the minimum version available, then, _our_ build would fail, and we would know that we need to either remove the dependency on the a-2.0 feature or increase the version specified in Build-depends. * a-2.0 is not guarenteed to be 100% backwards-compatible with a-1.0. Even a-1.0.1 is not guarenteed to be backwards-compatible. So, if the original author was really testing with a-1.0, then we are more likely to run into problems with a-2.0 (or even a-1.0.1) than a-1.0. We might say that a-1.0.1 is probably a bugfix for a-1.0 that does not change the API for the package. But, we can only guess about that; maybe a-1.1 is a bugfix release too, but probably not. Furthermore, it might be the case that the library/program in question is not affected by the bugs in a-1.0, in which case it is okay to use a-1.0 even if a-1.0.1 is available. And, if it is affected, then the Build-depends should be changed to a >= 1.0.1 anyway. Practically, a package author will often want his package to work with the minimum versions of its dependencies AND the maximum versions at the same time. To support this, we might want to add a flag to "configure" that says "choose the maximum versions instead of the minimum versions" which would result in the the current behavior. This would allow the package author to build and test his package twice, once with its minimum dependencies (by omitting the flag), and once with the latest versions (by including the flag). - Brian

2 1

dropWhileRev
by Henning Thielemann 07 Aug '05

07 Aug '05

Is this function worth to be added to Data.List? {-| Remove the longest suffix of elements satisfying the predicate. In contrast to 'reverse . dropWhile p . reverse' this works for infinite lists, too. -} dropWhileRev :: (a -> Bool) -> [a] -> [a] dropWhileRev p = foldr (\x xs -> if p x && null xs then [] else x:xs) []

3 3