On 14/08/2008, at 06:32, Duncan Coutts wrote:
On Wed, 2008-08-13 at 22:47 +1000, Roman Leshchinskiy wrote:
Again, I'm not arguing against a build system written in Haskell. I'd just like it to be completely separated from Haskell's packaging system. In particular, "polluting" a package description with build information seems wrong to me.
There is a huge overlap of course. The things needed to build a package tend to be the dependencies. The ability to automatically extract the dependencies from a package description is crucial as it is what enables automatic package management either directly or by conversion to distro packages. Tools like automake + autoconf do not give us that.
Right. Dependencies are part of a package description. That's what Cabal should do. It should provide a nice clean interface to the dependencies stuff for the build system to use. I don't think it does that at the moment; IIUC, it is all done by Distribution.Simple.
There is of course some separation possible, which in Cabal roughly corresponds to the stuff under Distribution.Simple vs everything else. We could split those two aspects into separate packages but it's not clear to me that we'd gain much by doing that.
My point isn't really about distribution, it's about coupling. My concern is that the syntax of .cabal files is increasingly based on what Distribution.Simple needs. This effectively makes all other build systems second class. It also loses us clean package descriptions which is what .cabal files should be. It's not too bad at the moment but will get worse as Distribution.Simple gets more complex since it will need more and more information. Just as an example, consider something like ld-options. This is obviously not a dependency and is basically only documented by how it is used by Distribution.Simple. It shouldn't be in .cabal, IMO. If a build system needs this information, it should be provided somewhere else.
There is still the Make build type which we could improve if people want it. That allows the declarative stuff to be given in the .cabal file (so that package managers can do their thing) and all the building is delegated to make. People have not shown any interest in this so it's never been improved much. The obvious disadvantage of using it is that you have to do a lot of work to make your build system do all the things that users expect.
But that is precisely my (other) point. A lot of that work is really unnecessary and could be done by Cabal since it only or mostly depends on the package information. Instead, it is implemented somewhere in Distribution.Simple and not really usable from the outside. For instance, a lot of the functionality of setup sdist, setup register and so on could be implemented generically and used by a make-based build system as well. Also, there is no easy way for build systems to work with the declarative stuff because a lot of that functionality is, again, part of Distribution.Simple. IMO, this is a direct result of the tight coupling between the package management and build system parts of Cabal. The other problem, of course, is that it isn't clear what exactly a build system should provide. IIUC, that's what "Building and installing a package" in the Cabal manual defines but there, we have things like this: setup test Run the test suite specified by the runTests field of Distribution.Simple.UserHooks. See Distribution.Simple for information about creating hooks and using defaultMainWithHooks. As a matter of fact, a lot of Cabal is documented in terms of what Distribution.Simple does. Again, this effectively shuts out other build systems. I'm sorry if this all sounds too negative, it shouldn't really. I think you guys have done a great job in implementing a system which is obviously very important to the community. I just somewhat disagree with the direction in which it is heading now. Roman