how to implement optional build-depends <was Cabal vs Haskell [sic]>

[Isaac Jones]

"S. Alexander Jacobson" <alex at alexjacobson.com> writes:

(snip)
> The spec says that build-depends identifies the packages "needed to
> build this one."
>
> If packages other than Ps may provide access to module B then the
> build-depends tag cannot identify the dependencies of module A because
> Ps are not necessary, only sufficient.
>
> Build-depends identifies necessity not sufficiency.

If that's a big concern, it's easy to fix.

I very much hope that the build-depends meaning will be expanded in
the future to express more options.  Build-depends in Cabal is
inspired by Debian build-depends which have a richer syntax.  For
instance, you can say:

Name: Foo
Build-Depends: Bar | Bang, Baz

I want Cabal to be able to do this some day.  It just wasn't the kind
of feature we wanted to focus on for Cabal 1.0. If you're very keen
for this feature, patches are accepted as usual.  It shouldn't be too
hard.  Tool support for Hackage would probably be a little harder, but
not much.

So here's what it would probably look like for Cabal:

- Write test cases.  Not as trivial as it might seem as first since
  there are a number of environmental issues to take into account.

- Alter the Distribution.Version.Dependency type to allow a list of
  options.

- At configure time, you check to see which of the dependencies are
  present.  If none are present, then you can't continue, if more than
  one is present, then you need some way to choose: Prompt the user,
  allow configure flags, pick the first in the list, whatever.  This
  will be simlar to how a version is chosen when the build-depends is
  a version range (already implemented).

- Now after this, the rest of the build process is the same.

- Write documentation :)

For hackage / cabal-get you'd need to perform a similar check to see
which packages are installed, and which you want to install before
downloading and building the rest of the dependencies.  This might
make the dependency analysis harder, but not that much (winking at
Lemmih).

This would possibly cause us to run into the module overlap limitation
more often.  If it were actually much of a problem, it would probably
show up in cases like this, particularly if Bar and Bang don't overlap
100% in their functionality and interface.  For now, I'd honestly
prefer to leave out optional dependencies until people are clammoring
for them.

They tend to show up in Debian in cases where two packages serve the
same purpose, like mail transfer agents, database back-ends, or
Haskell compilers.  For the short-term, until Hackage is running
smoothly for a little while, I think it's good to keep it simple.

>>> 5. Since more than one set of packages may contain the same set of
>>> modules, the current Haskell story cannot be consistent with the
>>> current Cabal story.
>> Why can't multiple packages have the same set of modules?
>
> Exactly!

Nothing prevents multiple packages from having the same set of
modules.

We simply can't compile them into a single program.  As has been said
(many) times already, this is a somewhat difficult engineering task,
but not a fundamental limitation.

peace,

  isaac