Build system idea
marlowsd at gmail.com
Thu Aug 28 11:31:22 EDT 2008
Roman Leshchinskiy wrote:
> On 28/08/2008, at 23:59, Simon Marlow wrote:
>> The important thing about Cabal's way of specifying dependencies is
>> that they can be made sound with not much difficulty. If I say that
>> my package depends on base==3.0 and network==1.0, then I can guarantee
>> that as long as those dependencies are present then my package will
>> build. ("but but but..." I hear you say - don't touch that keyboard
>> Suppose you used autoconf tests instead. You might happen to know
>> that Network.Socket.blah was added at some point and write a test for
>> that, but alas if you didn't also write a test for Network.Socket.foo
>> (which your code uses but ends up getting removed in network-1.1) then
>> your code breaks. Autoconf doesn't help you make your configuration
>> sound, and you get no prior guarantee that your code will build.
> Cabal doesn't give this guarantee, either, since it allows you to depend
> on just network or on network>x.
Indeed. That's why I was careful not to say that Cabal gives you the
guarantee, only that it's easy to achieve it.
>> Both systems are flawed, but neither fundamentally. For Cabal I think
>> it would be interesting to look into using more precise dependencies
>> (module.identifier::type, rather than package-version) and have them
>> auto-generated. But this has difficult implications: implementing
>> cabal-install's installation plans becomes much harder, for example.
> Interesting. From our previous discussion I got the impression that you
> wouldn't like something like this. :-)
Sorry for giving that impression. Yes I'd like to solve the problems that
Cabal dependencies have, but I don't want the solution to be too costly -
first-class interfaces seem too heavyweight to me. But I do agree with
most of the arguments you gave in their favour.
More information about the Glasgow-haskell-users