Build system idea

[Roman Leshchinskiy]

On 29/08/2008, at 01:31, Simon Marlow wrote:

> 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 yet!)
>>>
>>> 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.

True, it's easy to specify. But IIUC, if you do so you have to update  
your package whenever any of the packages you depend on changes even  
if that change doesn't affect you. This is a very high (if not  
prohibitive) cost and one which the autoconf model doesn't force on you.

>>> 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.

I'm not sure what you mean by first-class interfaces. Surely, if you  
specify the interfaces you depend on you'll want to share and reuse  
those specifications.

Roman