can't figure out how to use data-files

[claus]

looking into the docs, data-files seem easy. but when i try this:

-- p.cabal
name: p
version: 0
license: BSD3
build-depends: base
build-type: Simple
exposed-modules: P
data-files: file

-- Setup.hs
import Distribution.Simple
main = defaultMain

-- P.hs
module P(file) where
import Paths_p
file = getDataFileName "file"

-- file
data here

installation succeeds, but usage doesn't:

$ runhaskell Setup.hs --version
Cabal library version 1.5.1

$ runhaskell Setup.hs configure --prefix=c:/ghc/libraries --datadir='$prefix'
Configuring p-0...

$ runhaskell Setup.hs build -v
Creating dist\build (and its parents)
Creating dist\build\autogen (and its parents)
Preprocessing library p-0...
Building p-0...
Building library...
Creating dist\build (and its parents)
c:\ghc\ghc-6.9.20080514\bin\ghc.exe -package-name p-0 --make -hide-all-packages -i -idist\build -i.
-idist\build\autogen -Idist\build -odir dist\build -hidir dist\build -stubdir dist\build -package ba
se-3.0 -O P
[1 of 2] Compiling Paths_p          ( dist\build\autogen\Paths_p.hs, dist\build\Paths_p.o )
[2 of 2] Compiling P                ( P.hs, dist\build\P.o )
Linking...
c:\ghc\ghc-6.9.20080514\bin\ar.exe q dist\build\libHSp-0.a dist\build\P.o
c:\ghc\ghc-6.9.20080514\bin\ar.exe: creating dist\build\libHSp-0.a
c:\ghc\ghc-6.9.20080514\gcc-lib\ld.exe -x -r -o dist\build\HSp-0.o.tmp dist\build\P.o

$ runhaskell Setup.hs install
Installing: c:/ghc/libraries\p-0\ghc-6.9.20080514
Registering p-0...
Reading package info from "dist\\installed-pkg-config" ... done.
Saving old package config file... done.
Writing new package config file... done.

$ ghcii.sh
GHCi, version 6.9.20080514: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude> :browse P
file :: IO FilePath
Prelude> P.file
Loading package p-0 ... linking ... <interactive>:
c:/ghc/libraries\p-0\ghc-6.9.20080514\HSp-0.o: unknown symbol `___stginit_pzm0_Pathszup_'
ghc.exe: unable to load package `p-0'
Prelude> :set -package p
package flags have changed, ressetting and loading new packages...
Loading package p-0 ... linking ... ghc.exe:
c:/ghc/libraries\p-0\ghc-6.9.20080514\HSp-0.o: unknown symbol `___stginit_pzm0_Pathszup_'
ghc.exe: unable to load package `p-0'
>

what am i doing wrong?

[duncan]

You're not listing Paths_p in the other-modules field so Cabal does not know that you are using it so it does not get included into the library.

See ticket #218.

[duncan]

Oops, I mean see ticket #128.

[claus]

Thanks, that works! But since Paths_p was generated behind my back, it seems odd that I have to list it myself, especially since a non-empty data-files field makes no sense at all without it (no dependency chasing needed for this one).

I'd suggest to (a) mention this in the user guide and (b) add Paths_package implicitly if the cabal file has data-files (not much sense giving an error message if the fix is uniquely determined).

Btw, having --prefix not apply to all dirs is very counter-intuitive.

[duncan]

Replying to claus:

Thanks, that works! But since Paths_p was generated behind my back, it seems odd that I have to list it myself, especially since a non-empty data-files field makes no sense at all without it (no dependency chasing needed for this one).

Well yes and no. There has always been the requirement that packages list all the modules they use. Packages can want to use the Paths module even if there are no data files and people sometimes install data files without needing to find them at runtime in the standard way.

In any case this will all go away once we have dependency chasing. There will be no need to specify other-modules at all.

I'd suggest to (a) mention this in the user guide

Yes, it's not explicitly documented that every module must be listed either in exposed-modules or other-modules. So we should add that and at the same place point out that this includes modules generated by Cabal if the package chooses to use them.

and (b) add Paths_package implicitly if the cabal file has data-files (not much sense giving an error message if the fix is uniquely determined).

I don't think this is necessary or necessarily a good idea.

Btw, having --prefix not apply to all dirs is very counter-intuitive.

In most circumstances all the dirs are relative to $prefix however for the specific case of data files of packages containing a library and only on Windows, the default is not relative to the prefix.

I can't remember exactly why it's this way but I think it's to do with relocatable packages and being able to find the data files for libs. Libraries with data files cannot be relocatable since we cannot then find the files at runtime.

[claus]

In any case this will all go away once we have dependency chasing. There will be no need to specify other-modules at all.

Good, looking forward to it!

I'd suggest to (a) mention this in the user guide

Yes, it's not explicitly documented that every module must be listed either in exposed-modules or other-modules. So we should add that and at the same place point out that this includes modules generated by Cabal if the package chooses to use them.

I was specifically thinking of 3.2, something like: "if your package wants to install and use data files, remember to list the files in data-files and the Paths_package module in other-modules".

and (b) add Paths_package implicitly if the cabal file has data-files (not much sense giving an error message if the fix is uniquely determined).

I don't think this is necessary or necessarily a good idea.

Okay. In that case I'd suggest issueing a warning "There are data-files, but Paths_package isn't listed in other-modules (see user guide, 3.2)".

Perhaps it would be useful to distinguish extra-files from data-files?

Btw, having --prefix not apply to all dirs is very counter-intuitive.

In most circumstances all the dirs are relative to $prefix however for the specific case of data files of packages containing a library and only on Windows, the default is not relative to the prefix.

It being an exception to the rule is exactly why I find it counter-intuitive and easy to forget/get wrong.

I can't remember exactly why it's this way but I think it's to do with relocatable packages and being able to find the data files for libs. Libraries with data files cannot be relocatable since we cannot then find the files at runtime.

When you remember the reason, could you please add it to the users guide, where --prefix is explained?

[duncan]

Tue Jul 29 17:03:08 BST 2008  Duncan Coutts <duncan@haskell.org>
  * Document more clearly that every modules must be listed
  in one of the fields exposed-modules, other-modules or main-is
  Add an extra note to the section on the Paths_pkgname module
  as the fact that it's automatically generated confuses people.

[duncan]

Replying to claus:

In most circumstances all the dirs are relative to $prefix however for the specific case of data files of packages containing a library and only on Windows, the default is not relative to the prefix.

It being an exception to the rule is exactly why I find it counter-intuitive and easy to forget/get wrong.

I can't remember exactly why it's this way but I think it's to do with relocatable packages and being able to find the data files for libs. Libraries with data files cannot be relocatable since we cannot then find the files at runtime.

When you remember the reason, could you please add it to the users guide, where --prefix is explained?

See #466 about this issue of the datadir not being relative to the prefix by default for Windows library packages.

We should eliminate this exception by handling relocatable packages differently, explicitly and generally better (see #469).