The bootstrap.sh script has to go
jakewheatmail at gmail.com
Tue Dec 30 20:23:19 UTC 2014
I have some ideas about how to improve the bootstrap.sh situation.
Rewriting in haskell sounds like a good idea to avoid the shell script
Simplify the bootstrap.sh process:
* always use a fixed set of versions of packages for the dependencies
* always bootstrap in a sandbox, and ignore packages in the global and
user package database - only reuse an existing package if it is in
the bootstrap sandbox and is the exact version expected
* possibly the set of versions of packages can be in an external file,
and possibly bootstrap can optionally try to download a new
dependencies version file when bootstrap.sh is run
* possibly the set of dependency package versions can be different for
different versions of ghc
* there could even be a process which uses a cabal-install to generate
the list of bootstrap.sh dependency versions in some automatic way
* choose the bootstrap to always do shared or non shared (not sure
which is best). Don't have options to do profiling, haddock, change
the prefix, etc. at all.
* if any dependency packages need specific flags, then this can be
hardcoded in some way linked to in the dependency package versions
This allows more reliable bootstrapping on a new system, and more
reliable bootstrapping e.g. if you delete the cabal-install binary and
also happen to have all sorts of stuff in your user package database.
In this system, if you want the latest cabal-install and you want it
with the latest packages, or with profiling, haddock, etc. then you
can just bootstrap.sh, then use the cabal-install binary to build a
latest and greatest cabal-install with the full constraint solver and
any options you want. I think this is a reasonable compromise to allow
easy maintenance and a reliable and painless bootstrap.sh process.
I can work on some variation of this if it sounds acceptable.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cabal-devel