Re: About cabal and compatibility

11 Dec 2005

      On Saturday 10 December 2005 07:14 pm, you wrote:
...
Robert Dockins  writes:
...
[snip]
...
This would greatly simplify the Distribution.Simple.UserHooks
structure bringing it from 34 fields to 14 fields, or so.
Downsides: Making pre and post hooks would now be slightly harder, and
it would break existing hooks-using code.
I just want to mention that these kind of changes represent represent a
VERY big problem. I discussed that issue at some length in an email I
intended to send to this list very recently, but it seems to have gotten
lost.
Are you sure they represent a very big problem in practice and not
just in theory?
[snip]

Well, obviously it isn't a practical problem yet.  If it was we'd have people 
screaming about it on the lists.

The thing that got me thinking about it was Happy.  Its recently been put in a  
darcs, and Simon Marlow mentioned to me that they are looking at moving to 
Cabal for the build system.

The Happy build system now does two things that aren't your standard build 
actions:

1) It creates module which contains the version string before compilation
2) After compilation it runs CPP on a number of template files with various 
different "-D" options to genreate the parser templates.

I was messing around with doing these using user hooks and I ended up needing 
to tie pretty deeply into cabal even for the simple task 1).

I have attached my initial attempts so you can see what's happening.

The user hooks change you are talking about would require a complete rework of 
my Setup.hs file.  Its only ~130 lines, but then Happy is a pretty small 
project.
...
I only know of one or two packages that use the hooks.  Do you know of
backward compatibility problems that cabal has caused?
No, this is all speculation currently.
...
BTW, I just added a "cabal-version" field to cabal so that if a
package requires a particular version of cabal, it can say so.
Well, cabal the library already has to be invoked before the package file is 
even read!  If the Setup.hs doesn't typecheck because the cabal interfaces 
have changed, you won't even get that far.  To make a "cabal-version" field 
work you'd need some kind of bootstrapping step (which would itself need a 
very stable interface).
...
Further, my grand plan is that once stuff gets into hackage, we can
try making modifications and seeing if it breaks any packages, and if
so, offer patches to those package authors (since it's probably eaiser
for cabal hackers to write such patches than most package authors).
That depends on the complexity of the build system.  In my experience, just 
trying to figure out what a build system is doing can be pretty difficult.  I 
can't imagine you want to undertake the maintaince of other people's build 
systems.

OTOH, if Cabal is only aiming at pretty simple projects, this may never be an 
issue.
...
(snip)
...
I suggest that the cabal team very seriously consider using the Eternal
Compatibility in Theory method to manage interface change.
I'll look at this.
peace,
isaac