Build system idea
rl at cse.unsw.edu.au
Wed Aug 13 23:05:07 EDT 2008
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
> tend to be the dependencies. The ability to automatically extract the
> dependencies from a package description is crucial as it is what
> automatic package management either directly or by conversion to
> 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
> There is still the Make build type which we could improve if people
> it. That allows the declarative stuff to be given in the .cabal file
> 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
> 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:
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
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.
More information about the Glasgow-haskell-users