What build environments should Cabal support?

I recently submitted a pull request to Cabal to remove a block of code that lived inside a CPP conditional, that I suspect had not been compiled for years: https://github.com/haskell/cabal/pull/1148 I think it would be beneficial if we came up with a policy that allowed us to prune code like this more thoroughly: a clear statement of what libraries and compilers, at what versions, we intend Cabal to be used with. The situation we have at the moment is one where someone bumps a library version in one place, dropping support for some setup in the name of simplicity, but because there is no universal policy, other code to take care of that setup may remain. Code like the stuff I removed continues to exist in a state of limbo, and it is highly likely that when changes are made that break it, no-one will notice, since no-one is testing on that setup anymore. The result is a far more confusing and intricate scattering of CPPery than any of us want to deal with. The README still contains advice for users of GHC 6.4.1. I think it would be wise to bin that and replace it with a more explicit statement of exactly which targets we are programming to. Key questions we need to answer are: - what is the oldest version of GHC we intend to support? - do we still support Hugs? what about other non-GHC implementations?

Hi Ben, On Thu, Dec 13, 2012 at 02:51:12AM +0000, Ben Millwood wrote:
- what is the oldest version of GHC we intend to support? - do we still support Hugs? what about other non-GHC implementations?
The HACKING file in the root directory says Dependencies policy ------------------- Cabal's policy is to support being built by versions of GHC that are up to 3 years old. Note that this is what compilers you can use to build Cabal, not what compilers Cabal can build libraries for. Thanks Ian

Do we therefore have no interest in compilers other than GHC? Can we
drop all instances of ifdef __HUGS__ from the code?
I think doing so would require a reasonable amount of work, but would
significantly lower the barrier to contributing to Cabal.
On Thu, Dec 13, 2012 at 3:04 AM, Ian Lynagh
Hi Ben,
On Thu, Dec 13, 2012 at 02:51:12AM +0000, Ben Millwood wrote:
- what is the oldest version of GHC we intend to support? - do we still support Hugs? what about other non-GHC implementations?
The HACKING file in the root directory says
Dependencies policy -------------------
Cabal's policy is to support being built by versions of GHC that are up to 3 years old.
Note that this is what compilers you can use to build Cabal, not what compilers Cabal can build libraries for.
Thanks Ian
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

On Fri, Dec 14, 2012 at 3:29 PM, Ben Millwood
Do we therefore have no interest in compilers other than GHC? Can we drop all instances of ifdef __HUGS__ from the code?
I think doing so would require a reasonable amount of work, but would significantly lower the barrier to contributing to Cabal.
I think so. To my knowledge there's no one who's actively maintaining and testing the Hugs support in Cabal. It's most likely broken. -- Johan

On 14 December 2012 23:33, Johan Tibell
On Fri, Dec 14, 2012 at 3:29 PM, Ben Millwood
wrote: Do we therefore have no interest in compilers other than GHC? Can we drop all instances of ifdef __HUGS__ from the code?
I think doing so would require a reasonable amount of work, but would significantly lower the barrier to contributing to Cabal.
I think so. To my knowledge there's no one who's actively maintaining and testing the Hugs support in Cabal. It's most likely broken.
We should distinguish the compilers that can build Cabal, from those that cabal supports. Cabal supports several compilers that cannot themselves build Cabal. I am happy to drop the support for building Cabal using hugs and nhc as I don't believe they have been used for some years. In particular this will let us fully use new-style IO exceptions, and the new createProcess function. Duncan

On Fri, Dec 14, 2012 at 3:51 PM, Duncan Coutts
We should distinguish the compilers that can build Cabal, from those that cabal supports. Cabal supports several compilers that cannot themselves build Cabal.
I am happy to drop the support for building Cabal using hugs and nhc as I don't believe they have been used for some years.
In particular this will let us fully use new-style IO exceptions, and the new createProcess function.
Sounds good. Lets remove any __HUGS__ and __NHC__ ifdefs then!

On Fri, Dec 14, 2012 at 11:29:23PM +0000, Ben Millwood wrote:
Do we therefore have no interest in compilers other than GHC? Can we drop all instances of ifdef __HUGS__ from the code?
It was intended to mean only that older versions of GHC aren't supported, not other Haskell implementations. I'm not sure what opinions are about supporting other impls. Thanks Ian
participants (4)
-
Ben Millwood
-
Duncan Coutts
-
Ian Lynagh
-
Johan Tibell