patch applied (packages/regex-base): Make setup scriptcompileagain after recent Cabal changes

[Duncan Coutts]

On Sat, 2007-09-01 at 19:13 +0100, Ross Paterson wrote:

> Cabal really is a special case.  The API is still much too immature to
> stabilize, which is why it's handled differently from the other libraries.
> It was never claimed to be stable.  However a package that uses a
> boilerplate Setup.hs (as 90% of the packages on Hackage do) needs only
> backwards compatibility of the .cabal format, and that has been carefully
> preserved.  With the recent improvements to Cabal, fewer packages will
> need the tailored setup scripts that are so fragile.  To impose extra
> constraints on the Cabal API at this point would make it harder to make
> the wholesale cleanups and enhancements needed to benefit all the other
> packages, such as Thomas's recent implementation of configurations.
> 
> There is a common issue, but it's the "birthpangs of a new package
> system".  Pouring concrete over Cabal in its current state won't help.

I fully agree.

We've done a lot of work on Cabal recently fixing a huge long list of
bugs, complaints and feature requests. None of this would have been
possible without doing lots of refactoring at the same time. Anyone is
welcome to look at the internal code before and after too see what I
mean. We still need to make significant further internal API changes to
keep the code sane, to get features to be implemented in one place
rather than spread throughout the code base.

So the internal APIs are not stable and we can't promise to make them
stable without halting all significant future development. On the other
hand we have been extremely careful with not breaking the Cabal file
format (and most of the command line interface). It's backwards
compatible and in many ways future compatible too (ie adding new fields
does not break old versions of Cabal, though it does generate warnings).

GHC adopting Cabal for it's library build system has driven many
improvements in Cabal but yes has caused quite a bit of breakage in GHC
HEAD and the associated libraries. This isn't too bad since we have Ian
on hand to keep things in sync.

For other libraries using trivial Setup.hs files it's fine.

I really don't know what to do to make the base split up easier. The
main problem is that there really is nothing that identifies a piece of
code as the package or module it lives in changes. The modules in
packages can overlap so the module name isn't sufficient, though it's
probably good enough in most cases.

I've also been guilty of changing the internal api of ByteString, though
I do note that it is only the internal api which we never promised to
keep stable. The only changes in the public part of the api were as a
result of requests and discussion on this mailing list (see unsafe
CString bits and renaming .Base to .Internal and .Unsafe to reduce
confusion).

Duncan