finding the dependecies of cabal packages

[Isaac Jones]

Brian Smith <brianlsmith at gmail.com> writes:

(snip)
> I think it is essential to be able to tell which build infrastructure
> is being used, and which hooks need to be executed, without looking at
> Setup.lhs. In fact, I think that the relationship between the Setup.hs
> and Package.cabal file is backwards. Imagine that there was no
> "Setup.hs," and that every Haskell implementation came with an
> executable that could process Cabal files.

Then you lose the ability for the packager to do the fiddly little
things that packagers need to do for their package.  Cabal is designed
the way it is so that you don't have to invent an entire new language
to support such things.

> Now, let's say a Cabal package descriptions had these entries:
>
>     Build-Infrastructure: Simple
>     Hooks: None

So you are limiting what the packager can do to pre-determined build
infrastructures.  Cabal's interface is generic; anything could be in
that Setup file, including stuff that no one but the packager uses.
This is necessary because one size does not fit all.

Cabal provides an interface, and an implementation of that interface.
If the interface is lacking in some way, we can fix that.

> If a package description had these entries:
>     
>     Build-Infrastructure: Simple
>     Hooks: Setup (preBuild, postBuild, postClean)
>
> it has the three hooks mentioned, which are exported from the
> package's Setup module. Each hook is just a function with the same
> type it has from Distribution.Simple.UserHooks. Each implementations's
> setup tool would determine how to call these hooks.

But how do you call the user's hooks?  And what if they want to do
something that can't be done with hooks?

> Now, if a package description had this entry:
>
>      Build-Infrastructure: Make
>
> Then, tools that don't have Make (e.g. VHS.NET) could gracefully say
> "Make is not a supported build infrastructure" or "Cannot build this
> package because make is not installed."
>
> Also, imagine being able to do this for a Cabal package that has:
>      Build-Depends: HUnit, HaXml

It seems to me that adding the single field that Duncan needs is a
better solution than completely changing the way cabal works, and
limiting the users in the process.

peace,

  isaac