A (in)sane idea about (never) breaking Setup.(l)hs files again
Marc Weber
marco-oweber at gmx.de
Tue May 6 13:24:25 EDT 2008
module Main where
import Distribution.Simple72
main = mainWithHooks ( .... )
Could be one way to achieve this goal in most simpler API changes (up to
rewriting the whole core using more monads as all information is pased)
How could it work?
The Cabal distribution ships with
src/Distribution/Simple1.hs:
import Distribution.Simple2
import Types1
import Types2
-- wrapper for the new Simple2 api exporting API1
[..]
src/Distribution/Simple2.hs:
import Distribution.Simple3
[..]
I guess you get the idea. This way API v1 uses API v2 using API v3 ..
using API vlatest.
There is another case: What happens if the Setup.hs fits a newer cabal
version (2) but you have only (1) installed?
You could get an api wrapper mapping API v2 back to API1 you have.
And the cool thing: Adding this wrapper could be automated because
reading the Distribution.SimpleX versions is simple..
Propably the best way handling this case is: Update your Cabal version
anyway :)
It's a nice documentation about how to upgrade your Setup files as
well.. because looking at the "dummy" files only calling the other API
versions should give you all you need.
I'm not sure about how everyone would like having
Distribution/Simple{1,2,3,4,5,6,7,8,9,...200}.hs files
But thinking about how many cabal using people could benefit from this
easy to accomplish up and downgrading it might be worth it.
Some small changes (removing the Bool arg in runTests) and the
flagVerbose change would be really trivial then without having to read
lots of Cabal code
I think Cabal devs know best how often this could have helped people ?
It would make the life of all package mantainers a lot easier.. and of
those devs having SetupX{1,2,3}.hs flying around.
You can't forget about all trouble.. just about some incompatibilies.
Any thoughts?
Marc Weber
More information about the cabal-devel
mailing list