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

[Claus Reinke]

>> it is almost as if everything feels free these days to evolve in non-
>> backwards-compatible ways, following the motto "what do i care
>> for my apis of yesterday?".

i picked cabal as an easily demonstrated *example*, not as the only
culprit. for instance, if base gets split up into smaller parts, and the
*remainder* gets called base, even though it no longer provides the
same functionality as the old base package, that is not cabal's fault.

i'm not interested in blame-games, and my concern is with a general
trend rather than any particular tool or library. as far as _stability only_
is concerned, there is nothing wrong with *adding* features or with
*cleaning up* existing code; the problems come when *externally
used* features are *removed* or *new dependencies* are introduced.

lets have a look at that base package example, for a change: if the
remainder had been called base-core and base had become a proxy
package that provides no functionality other than recording the new
dependencies needed to get hold of the old functionality, by
depending on the spin-off packages, then there wouldn't have been
any externally visible changes to base, old code depending on base
would still work as long as base was installed, and new code could
bypass base, using base-core and other spin-off packages directly.

same for cabal: if it learns to do new things, do old things in nicer
ways, or interpret more information, *that should not affect any old
code*. if old code breaks, that means that old information is no
longer accepted, old dependencies are no longer sufficient, or old
functionality is no longer provided.

> This is the development version, so you can't really expect it to
> be stable at all.

i'm not concerned with the development versions of cabal (and
again:none of this is specific to cabal), which i never expect to
see. i'm concerned with the versions of cabal that are in active
use, in ghc head, hackage or elsewhere.

if a version of some centrally important software (be it library
or tool) is used, then that version's functionality/api should be
supported for as long as practical. compatibility packages and
automatic translators are not ideal, but better than nothing;
simply abandoning old clients is the worst situation. ideally, new
versions of such software should still support old clients, while
warning about uses of deprecated functionality (somehow,
deprecation warnings have come to mean "it will be gone in
the next version", when it used to mean "it will not be here
indefinitely").

> So, could you please exclude Cabal (and stay with me when
> I say we hope to have things stable by the next ghc release),
> re-evaluate the situation excluding anything related to Cabal
> issues (ie, setup.lhs errors), and see if your issue still exists?

yes, it does. it just turns up in cabal so often because (a) there's
a lot of development there (which is great!-), (b) cabal is aiming
to become central to all haskell development (which is rather
a huge burden of responsibility). the more cabal succeeds, the
more maintenance issues will be related to cabal, and the more
cabal is used, the higher the standards for backwards-compatibility
it should aspire to achieve.

</soapbox> :-)
claus