Build system idea

[Roman Leshchinskiy]

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