[Haskell-cafe] Re: ANN: Takusen 0.8
duncan.coutts at worc.ox.ac.uk
Thu Mar 6 06:14:17 EST 2008
On Thu, 2008-03-06 at 08:27 +0000, Alistair Bayley wrote:
> > Yeah, I really like the single package model. And the Setup.hs does work
> > -- I just can't use cabal 1.2.x or 1.3.x or 1.4.x with it :)
> I beg to differ. We have three cabal Setup files in the repo: Setup.hs
> (for the 1.2 series), Setup-1162.hs, and Setup-114.hs. Setup.hs should
> work with ghc-6.8 out of the box, Setup-1162.hs should work with
> ghc-6.6 (once you've upgraded cabal to 18.104.22.168), and Setup-114 I just
> kept because, well, someone might find it useful. The idea is that you
> should upgrade cabal to the latest (currently 1.2) and use the
> Setup.hs, but in case you can't, the older Setup's are hanging around
> to help.
> That said, I haven't tested with the latest cabal release, so perhaps
> it's borken again.
I've no idea why people are talking about a Cabal 1.4 release, there's
been no such thing. :-)
BTW, it's not your responsibility to make your Setup.hs compatible with
the current development version of Cabal, it's our aim to keep Cabal-1.4
compatible with existing Setup.hs scripts. That said, I did have a look
at your Setup.hs and is does use rather a lot of internal Cabal apis.
> > What do you do if the user does not have the ODBC or the postgresql C
> > libs installed? Do they have to have all backends installed to use just
> > one?
> No, we do something you might consider fairly hideous.
Yes, I saw that and was appropriately horrified :-)
> Having established which libraries are installed on the user's system, we
> then use that list to filter the module list. So if you don't have
> Oracle or Sqlite installed, the module list is pruned so that these
> modules are no longer present in the build. This isn't stricly
> necessary; another approach would be to simlply build all of the
> modules. This works fine with ghc (which uses gnu ld for linking).
> However, with ghci (which has a custom module loader and linker, I
> it seems to attempt to link all of the modules in the lib, and
> this fails badly if you don;t have every back-end DBMS client
> The only way I could find to fix that was to adjust the
> build to only include modules that will link successfully (i.e. those
> for which you have a DBMS client installed).
Yes, or split into multiple libs.
I looked yesterday at a slightly nicer way of doing what you're already
doing. We can use flags to turn on/off the various backends. What is
tricky is doing that such that the default is chosen automagically.
We have a way to set the default value of a flag, but just constants
True/False. We don't have any mechanism to adjust flags based on code in
I'll ponder it.
More information about the Libraries