June 2005 - Libraries

RE: Cabal help please
by Simon Marlow 16 Jun '05

16 Jun '05

On 16 June 2005 15:36, Adrian Hey wrote: > Hello, > > I'm just getting around to tidying up the AVL library and releasing > a new version and, of course thinking about Cabalising it too. But > I'm finding difficult to figure out how to do this from the > Cabal docs and Distribution library haddock. > > Anyway, what I want to do is.. > Run cpphs on all the sources > Compile the results using -split-objs (for ghc at least). Cabal doesn't support -split-objs at the moment. To do this you'll need to write your own Makefile and hook it up to Cabal (possible, but a bit fiddly I believe). Cheers, Simon

3 3

Workaround for building profiling libs and apps with Cabal
by Satnam Singh 16 Jun '05

16 Jun '05

I recently tried to build a version of an application with Cabal to use with profiling by simply adding: ghc-options: -prof -auto-all to my Cabal file but this did not work because the generated .hi interface files ended in .hi and not .p_hi as expected and the .o and .a files also did not have the expected names. As a work-around I wrote a small script "fixhi" to create symbolic links for the expected filenames. The script can be adjusted to perform a rename by substituting the "ln -s" with "mv". The script is at the end of the message. It is designed to be run in the install directory of the package for a specific version e.g. lagavulin> pwd /c/Program Files/lava/lava-0.1 lagavulin> fixhi Symbolically linking ./Lava/Below.hi to ./Lava/Below.p_hi Symbolically linking ./Lava/Beside.hi to ./Lava/Beside.p_hi Symbolically linking ./Lava/Bit.hi to ./Lava/Bit.p_hi Symbolically linking ./Lava/Classes.hi to ./Lava/Classes.p_hi Symbolically linking ./Lava/Col.hi to ./Lava/Col.p_hi <...lots of lines deleted...> Symbolically linking ./Xilinx/Adder.hi to ./Xilinx/Adder.p_hi Symbolically linking ./Xilinx/Comparator.hi to ./Xilinx/Comparator.p_hi Symbolically linking ./Xilinx/Components.hi to ./Xilinx/Components.p_hi Symbolically linking ./Xilinx/OneBitAdder.hi to ./Xilinx/OneBitAdder.p_hi Symbolically linking ./Xilinx/OneBitSubtractor.hi to ./Xilinx/OneBitSubtractor.p_hi Symbolically linking ./Xilinx/Subtractor.hi to ./Xilinx/Subtractor.p_hi Symbolically linking ./Xilinx.hi to ./Xilinx.p_hi Symbolically linking ./HSlava-0.1.o to ./HSlava-0.1_p.o Symbolically linking ./libHSlava-0.1.a to ./libHSlava-0.1_p.a lagavulin> Application of the script should be idempotent. A simple change could allow the script to take a path to the installation so it can be run from elsewhere (e.g. a Makefile). I also expected when I used ghc --make to compile my programs that use this library to also be automatically compiled with "-prof -auto-all" but I guess that must be another option to Cabal and I had to add this to the ghc compilation command for the clients of this library. Hopefully the next version of Cabal will make it easier to build profiled and non-profiled versions of libraries and applications. Until then maybe the script below might provide some utility to others. I've only tested it under Microsoft Windows with msys (other OS-es are kind of hard to come by where I work). Cheers, Satnam Singh Microsoft One Microsoft Way Redmond Washington 98052-6399 USA #!/bin/sh # Workaround script for producing profiling interface files and libs # with the expected extension for use with Cabal. # Find and symbolically link to the interface files. for intfFile in `find . -name "*.hi" -print` do echo Symbolically linking $intfFile to ${intfFile%*.*}.p_hi ln -f -s $intfFile ${intfFile%*.*}.p_hi done # Find all the libraries and objects and link to them too. # First delete old profiling library files. rm -rf *_p.a *_p.o for objFile in `find . -name "*.o" -print` do echo Symbolically linking $objFile to ${objFile%*.*}_p.o ln -f -s $objFile ${objFile%*.*}_p.o done for libFile in `find . -name "*.a" -print` do echo Symbolically linking $libFile to ${libFile%*.*}_p.a ln -f -s $libFile ${libFile%*.*}_p.a done

3 2

RE: Default prefix for Cabal on Windows
by Simon Marlow 16 Jun '05

16 Jun '05

On 16 June 2005 09:08, Axel Simon wrote: > On Wed, 2005-06-15 at 20:56 -0700, Daan Leijen wrote: >> I think that "c:\Program Files" is already too cluttered, maybe we >> should use: >> >> 1) C:\Program Files\Haskell\<package-name>-<version> >> >> or >> >> 2) C:\Haskell\<package-name>-<version> >> >> where "Haskell" could also be "Packages" I guess. > > I strongly reject Daan's point :-). The prefix should come from the > registry, since that is the Windows way. "C:\Program Files" doesn't > even exists on foreign-language Windows machines. And programs which > assume they know that C: is the right (i.e. only) hard disk are a > pain, since you can do a network install where only Registry entries > are local. Ok, so $(ProgramFiles) is determined by the registry. Taking into account comments so far, I think we have: prefix = $(ProgramFiles)\Haskell\$(PackageName)-$(Version) libdir = $(prefix)\$(Compiler)-$(Version) bindir = $(prefix)\bin these are only defaults - users & packagers are free to change them. Sound reasonable? Cheers, Simon

2 1

Cabal help please
by Adrian Hey 16 Jun '05

16 Jun '05

Hello, I'm just getting around to tidying up the AVL library and releasing a new version and, of course thinking about Cabalising it too. But I'm finding difficult to figure out how to do this from the Cabal docs and Distribution library haddock. Anyway, what I want to do is.. Run cpphs on all the sources Compile the results using -split-objs (for ghc at least). Put the all the resulting objs in libHSDataTreeAVL.a Run haddock on some of the sources (but not all). .. and I'd like to do this without depending on gnu make. So could someone tell me if this is possible with Cabal as it is at the moment? (and if so, how I should do this). Thanks -- Adrian Hey

2 1

RE: Default prefix for Cabal on Windows
by Simon Marlow 16 Jun '05

16 Jun '05

On 15 June 2005 05:49, Brian Smith wrote: > The documentation states in Section 3.1 that the default value of > "prefix" is "/usr/local" on Unix. However, it doesn't specify what the > prefix is on Windows. I found that the default value for prefix is: > C:\Program > Files\<package-name>\<compiler-name>-<compiler-version>. For example, > version 1.0 of a package named "Foo" compiled with GHC > 6.5 would have a default prefix of: > C:\Program Files\Foo\ghc-6.5 > > I think that a better default value of prefix on Windows would be: > C:\Program Files\<package-name>-<package-version> > e.g.: > C:\Program Files\Foo-1.0 > > In particular, I think it is undesirable to have the name and version > of the compiler embedded in the default prefixes. Ok by me to add the package version. The compiler version is there to avoid conflicts in the case when you have multiple versions of GHC installed and the package is installed for each one. However, I don't think we currently include the compiler & version in the default $(libdir) on Unix, so whatever we do we should do it consistently. Cheers, Simon

5 4

RE: irrelevant package
by Simon Marlow 15 Jun '05

15 Jun '05

On 15 June 2005 15:19, Duncan Coutts wrote: > On Wed, 2005-06-15 at 14:47 +0100, Simon Marlow wrote: >> On 15 June 2005 13:49, Duncan Coutts wrote: >> >>> I think the bug in this case is the fact that the modules are >>> considered to be part your program even though they are never >>> imported (directly or indirectly) or even any modules from the same >>> package are imported (if we take the reasonable assumption that if >>> one module from a package becomes part of your program's module >>> namespace then all of them do). >> >> I agree, and I've been putting some serious thought into whether we >> can relax this restriction, and allow local modules to shadow package >> modules. > > I'm not sure that allowing local modules to shadow package modules is > really necessary in this case. > > There is the simpler (but very important) case where the local module > doesn't shadow any package module - at least not a package that is > used in the current program. So 'all' that needs to be done is to > track which packages are actually used in a program (perhaps this is > harder than I imagine). So if we never import any module from package > Foo which depends on util-1.0 then util's modules are not brought > into the module name space. > > GHC obviously does this correctly when linking, that is figure out > which packages are used by the program, otherwise every program > produced by ghc --make would be linked against absolutely every > library used by every exposed package. So we just need to do the same > thing when compiling and note that the module name space does not > include modules from packages which are not imported. So an exposed > packages modules (and therefore all of the modules in dependent > packages) are not considerd to be part of the program's module > namespace unless one or more of them is actually imported. Right, GHC does know the real package dependencies of the program, and it uses those for linking, but only for --make and GHCi. Ordinary batch linking (ghc Main.o -o foo) doesn't know the dependencies, and there's no good way for it to find out. But we currently require you to give explicit -package flags for batch linking, so I suppose this is ok. I called it shadowing because I think it is a kind of shadowing: when you import a module, the compiler has to search for it, and the proposal is that if the module is both on the local search path and in a package, then the local module takes precedence. GHC 6.4 currently takes the package module, and HEAD emits an error message in this case. I'm not proposing that you should be able to replace, say, Network.Socket with your own local version and yet still use the network package - that would definitely lead to problems, and the compiler should check for that. The problem with all this is that GHC internally has a function of type isHomeModule :: DynFlags -> Module -> Bool where DynFlags contains the package database. This becomes harder to implement if a package module can be a local module under certain circumstances... hmm, this isn't as easy as I thought. Cheers, Simon

1 0

RE: irrelevant package
by Simon Marlow 15 Jun '05

15 Jun '05

On 15 June 2005 13:49, Duncan Coutts wrote: > I think the bug in this case is the fact that the modules are > considered to be part your program even though they are never > imported (directly or indirectly) or even any modules from the same > package are imported (if we take the reasonable assumption that if > one module from a package becomes part of your program's module > namespace then all of them do). I agree, and I've been putting some serious thought into whether we can relax this restriction, and allow local modules to shadow package modules. Fortunately command-line linking works, because the linker links libraries lazilly. As long as we never have to use a linker that doesn't have this property, we're ok. We still have to check for real conflicts: where the package is really part of the dependencies of the program, and also shares a module name with the program. This can be checked for when compiling a module. GHCi just about copes, by virtue of linking in packages on demand. But, if you happened to require a package P and later changed the program so that it didn't need P any more but used a module name from P, you would have to restart GHCi. So, I think it's ok, just about. Cheers, Simon

2 1

RE: irrelevant package
by Simon Marlow 15 Jun '05

15 Jun '05

On 14 June 2005 13:03, Duncan Coutts wrote: > On Mon, 2005-06-13 at 16:06 +0100, Simon Marlow wrote: >> This is "fixed" in newer versions of Cabal. >> >> However, you are heading for problems here. When you install a >> package P that includes a module M, you prevent the user from having >> any modules called M unless they say '-hide-package P' (see previous >> discussions on this subject). >> >> For this reason, we strongly recommend using hierarchical module >> names. >> >> At the moment, Cabal "exposes" all the packages it imports. Perhaps >> we should have an option to install an unexposed package, to allow >> installation of packages that contain non-hierarchical module names. >> Isaac - what do you think? > > But remember that any exposed dependent package of P effectively > exposes package P anyway. So it's not the case that you can install > an unexposed package and assume that it'll all be ok. Any package > installed later can come along and expose your package and you're > back to the problem that no programs/libs with your module M can now > be complied (without several -hide-package flags). A package is never exposed as a result of being depended on by another package, but its modules are brought into the module namespace. The difference is that you can import modules from an exposed package, you can't from a hidden package. This is true even if the hidden package is depended on by another exposed package. Cheers, Simon

2 1

Default prefix for Cabal on Windows
by Brian Smith 15 Jun '05

15 Jun '05

Hi all, The documentation states in Section 3.1 that the default value of "prefix" is "/usr/local" on Unix. However, it doesn't specify what the prefix is on Windows. I found that the default value for prefix is: C:\Program Files\<package-name>\<compiler-name>-<compiler-version>. For example, version 1.0 of a package named "Foo" compiled with GHC 6.5 would have a default prefix of: C:\Program Files\Foo\ghc-6.5 I think that a better default value of prefix on Windows would be: C:\Program Files\<package-name>-<package-version> e.g.: C:\Program Files\Foo-1.0 In particular, I think it is undesirable to have the name and version of the compiler embedded in the default prefixes. Regardless of whether or not it is changed, this would be another good thing to put into the documentation. Regards, Brian

1 0

RE: irrelevant package
by Simon Marlow 14 Jun '05

14 Jun '05

On 13 June 2005 14:34, Serge D. Mechveliani wrote: > I am testing packages in ghc-6.4. > I set > docon.cabal, > > which declares dependence on `data': build-depends: data > The attempt to build docon by > > cd $doconSource > runhaskell Setup.hs configure --ghc --prefix=$doconSource/inst > runhaskell Setup.hs build > > produces > > configuring ... > compiling ... > ... > DPrelude.hs:1:0: > Module `DPrelude' is a member of package dumatel-1.2.6.4. > To compile this module, please use -ignore-package > dumatel-1.2.6.4. > > These does exist a package dumatel-1.2.6.4, and both the above > packages have DPrelude among the module names. > But why does Cabal look into irrelevant package? The dependence is > set: only `data'. This is "fixed" in newer versions of Cabal. However, you are heading for problems here. When you install a package P that includes a module M, you prevent the user from having any modules called M unless they say '-hide-package P' (see previous discussions on this subject). For this reason, we strongly recommend using hierarchical module names. At the moment, Cabal "exposes" all the packages it imports. Perhaps we should have an option to install an unexposed package, to allow installation of packages that contain non-hierarchical module names. Isaac - what do you think? Cheers, Simon

2 1