Re: [Haskell-cafe] Dynamic package information with Setup.hs

you should look at libs that have c libs embedded in them approach it. a good simple example would be lz4hs. Its really quite simple and doesn't require crazy hacks On Thu, Nov 21, 2013 at 4:25 PM, Thiago Padilha wrote:

On Thu, Nov 21, 2013 at 5:10 PM, Peter Simons wrote:

...

You can distribute a shell script that tries to build the C library and the Haskell library with convenient defaults, i.e. your script should call

cabal configure --extra-include-dirs=PATH --extra-lib-dirs=PATH

with appropriate paths after having built the C code, but please make sure that your Haskell package works fine for people who want to build the C library themselves without using your script.

Peter,

My reason for taking this route is to simplify the installation by making the C library a transparent part of the package. This is similar to the haskell bindings to zlib( the difference is that it bundles zlib source code in the 'cbits' directory since zlib build is simple everything just works).

This is common in package managers for other platforms(node.js, python) as it simplifies installation by users that have little experience with building C packages.

The goal is to have a generic Setup.hs file that I can use for packaging haskell bindings to libraries that have non-trivial build procedures, and still have everything working after a simple 'cabal install LIB'

With that said, I agree that allowing customization by advanced users is essential. Like you suggested, I already use the 'extra-libraries' field without specifying extra-lib-dirs/include-dirs.

I still would like to follow the automatic build route with the following changes:

- The Setup.hs file will only invoke the download/build script if the --extra-lib-dirs/--include-dirs weren't passed to cabal(I believe the Args argument for the preConf hook is suitable for that) - An additional flag could be provided for users wanting to build against the system's version of the library.

This should hide the installation details by providing reasonable defaults (like a library version that is guaranteed to work with the binding) while still giving full control to advanced users.

What do you think? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe