Re: finding the dependecies of cabal packages

On 7/28/05, Isaac Jones wrote:

Brian Smith 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