cabal design

[Simon Marlow]

On 16 September 2005 18:03, Isaac Jones wrote:

> "Simon Marlow" <simonmar at microsoft.com> writes:
> 
>> Ok, I've read through this discussion.  Could somebody explain to me
>> why this whole "virtualization" thing can't be solved by simply
>> adding the flag 
>> 
>>   --package-db=<file>
>> 
>> to Cabal?  It would be another option in the --user/--global family.
>> The idea isn't new - I'm sure we've discussed this before.  It seems
>> to suffer from none of the problems of the other suggestions, but
>> perhaps I'm missing something.  For Hugs, the <file> would actually
>> specify a directory.  Additionally, --package-db=<file> is a step on
>> the way to other things that we want to do (--in-place).
> 
> The problem I have with --package-db= as a directory for Hugs (and
> nhc, and jhc) is that it conflicts with the meaning of the --prefix
> flag.  That is, if you specify a package database, it changes the
> location of the installation, which is not what you might expect.
> Also, we'd have to make sure people don't try to use --prefix and
> --package-db together in the case of Hugs (unless they're equal).

Ah, I has read the section "Hugs Package Database" on the wiki and for
some reason my brain had accepted it as The Truth rather than just a
proposal.  

Nevertheless, such a setup is already possible using symbolic links, at
least on Unix.  I think that assuming a level of indirection between the
package database and the actual installed location of the package is not
a bad thing - Hugs will catch up.  This isn't so bad.  To be precise:

  --package-db works fully for GHC

  --package-db works fully for Hugs on Unix-like systems, using symbolic
  links.

  --package-db will not work on Windows with Hugs, currently.

> Another option, since this will only really work for GHC, is to add
> --ghc-options and --ghc-pkg-options and people can specifcy the
> database they want, and it'll be clear that it's not a portable
> option.

That's ok, but not as attractive (IMO).  Other systems will want to have
the same facilities, and we'll end up with users of Cabal having to know
the right --<foo>-options flags to pass to Cabal for their compiler.  If
we standardise on the idea of a package database as a filesystem path,
which should be enough for everyone, then we can provide a portable
interface.

> So for the sake of those who haven't read the wiki page, here's my
> --root= proposal.  This basically directly implements "virtualization"
> in Cabal:
> 
>     * For GHC
>       o --prefix now becomes $(ROOT)/$(PREFIX)
>       o the ghc-pkg file is stored in $(ROOT)/.whatever
>       o Cabal adds package-conf related flags to ghc and ghc-pkg to
>         look at $(ROOT)/.whatever.

*this* is the bit I have a problem with.  You haven't specified how we
figure out the value of ".whatever", and it looks like it should vary
depending on the value of $(ROOT), at least for GHC.  Also, having both
--root and --prefix is quite confusing - I don't think I fully grasp the
significance of having both options, and I'm sure it'll confuse users.

This just doesn't look as simple as the --package-db flag.

We want the ability to specify the package db anyway, and this gives us
virtualisation too.  Two birds with one stone!

Cheers,
	Simon