finding the dependecies of cabal packages

[Brian Smith]

On 7/28/05, Isaac Jones <ijones at syntaxpolice.org> wrote:
> 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
>
> > 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.

"Packager" is the maintainer of a package for a given platform,
seperate from the package author, right? Are you saying that the
packager will replace any Setup.hs/Setup.lhs provided by the package
author with his own version that does whatever "fiddly little things"
are necessary to integrate the Cabal package with the system's
packaging system? Is this what package maintainers for
Gentoo/Debian/etc. are actually doing? It seems like they are saying
they don't want to do that, and that they would rather generate their
packages directly from the .cabal file. I didn't see in the
documentation that we (users of Cabal) are supposed to expect this.

> > 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?

Firstly, if "they" want to do something that can't be done by hooks,
then it is likely that whatever they are doing isn't going to work in
other Cabal-enabled tools like VHS.NET and other such tools (one of
which I am working on). It would be nice if these tools could say
"Warning: this might not build correctly because it is not using the
simple build infrastructure" and/or "Warning: all build hooks will be
ignored." Currently, there is not a way for these tools to do this
easily.

Secondly, it would be a simple matter to have the tool generate its
own equivalent to the current "Setup.lhs" that looked something like:

    module Main(main) where
    import qualified Setup(preBuild, postBuild, postClean)
    import Distribution.Simple(defaultMainWithHooks,emptyUserHooks,
UserHooks(..))
    main = defaultMainWithHooks $ emptyUserHooks { 
              preBuild = Setup.preBuild,
              postBuild = Setup.postBuild,
              postClean = Setup.postClean }

I guess the important point is that there should be a way from looking
at the Cabal file to determine if a tool can be built using the
equivalent of "defaultMain." For example, an IDE might use the GHC API
to implement an "incremental build" feature, which would rebuild
projects upon detecting changes to the source files (like Eclipse
does). Futhermore, it might want to provide context-sensitive features
like autocomplete that Cabal doesn't provide, and that requires
knowledge of all source code dependencies in the source code.

Also, don't you think that GHCi should be able to read Cabal files so
that you don't have to say "ghci -cpp -fglasgow-exts -package X
-package Y -package Z MyModule" when all those options are already in
the Cabal file?

> > 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.

I don't see how my suggestion is limiting users, or even completely
changing the way Cabal works.

I will say that the current system seems inconvenient. For example, I
just made some changes to the Win32 library on my local machine. I
wanted to build and install the new version of Win32 using Cabal. The
.cabal file is there but there is no "Setup.hs." So, I either have to
add a Setup.hs myself, or reuse an existing one that is somewhere
else. (The Hugs build process uses the single
"fptools/libraries/Cabal/examples/hapax.hs" to build all its Cabal
packages, because none of them provide their own "Setup.hs".) On one
hand, it doesn't make sense to have dozens of identical "Setup.hs"
files throughout fptools. On the other hand, every Cabal package is
expected to have its own Setup.hs, AFAICT.

- Brian