Re: Bootstrap.hs
On 11 January 2015 at 14:35, Johan Tibell wrote: > Overall I like this approach. One problem the old script suffered from was > that its goals and, in particular, non-goals weren't clearly stated. Lets > state the goal clearly: > > Goal: Be able to bootstrap a cabal-install binary of a bare GHC install > from https://www.haskell.org/ghc/download > Non-goal: Be able to bootstrap using a modified global package DB or > using a user DB in an arbitrary state. > I would like to add a goal: Boostrap on a modified GHC install, as long as the global packages which come with GHC are not modified. It will ignore any packages added to global, or added to the user package database. I think this is useful for testing and for more convenient recovery if you delete cabal-install. (It already does this.) I think it would be a good idea if the platforms it is expected to work on nailed down a bit more clearly as part of the goals also - not sure what to do about Linux, but we can say which versions of Windows and OSX it is tested on. > > The latter is a non-goal because doing that well requires a constraint > solver. We've tried to to emulate that using regexes in the past and that > has become more and more untenable. The goal is met by the new Bootstrap.hs > by nailing down the exact version numbers to use. > > Questions about Bootstrap.sh: > > * Can we make it work in-tree? I tried it on master now and that didn't > work (because it tried to install Cabal-1.23 from Hackage, which doesn't > exist.) This is needed to we can run it on Travis to test it. > This is on my todo for this to work automatically. I think it will be pretty easy. > * We need to make sure it works on supported platforms: Linux, OS X, and > Windows. This is mostly about testing. > Can travis test on all these systems? What about e.g. Solaris or FreeBSD, which have had binary releases of GHC in the past? > * How can I test it in the current state? As mentioned above, > bootstrapping in the master branch didn't work. > The current work-around needs a working cabal-install, run 'cabal sdist' in the Cabal/ dir, then copy the .tar.gz to cabal-install/ and the Bootstrap.hs will pick it up. > * We should output a message once the install is done to tell the user > how to use the bootstrapped binary. > There is a small message, it can be changed/added easily. > In particular, we might want to tell the user to use it to reinstall > cabal-install not in a sandbox. > Is there any reason to do this? Won't the bootstrapped cabal install binary work fine for most users? Alternatively, it could rerun cabal-install automatically or optionally as part of the bootstrap, or it could copy the bootstrap binary to ~/.cabal/bin/ or something if this is desired. ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Bootstrap.hs
I have an draft rewrite of bootstrap.sh in haskell. I've tried to improve the maintainability of the code and reliability of running the bootstrap. https://github.com/JakeWheat/cabal/blob/bootstrap-hs/cabal-install/Bootstrap.hs Any feedback is appreciated! ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: Cabal 1.22 RC ready to test
On 3 January 2015 at 15:05, Johan Tibell wrote: > The error (https://travis-ci.org/haskell/cabal/jobs/45758614) is quite > perplexing: > > [62 of 77] Compiling Distribution.Client.Config ( > Distribution/Client/Config.hs, > dist/dist-sandbox-8940a882/build/cabal/cabal-tmp/Distribution/Client/Config.o > ) > Distribution/Client/Config.hs:56:12: > Module > ‘Distribution.Simple.Compiler’ > does not export > ‘DebugInfoLevel(..)’ > cabal: Error: some packages failed to install: > cabal-install-1.22.0.0 failed during the building phase. The exception was: > ExitFailure 1 > > Distribution.Simple.Compiler most definitely does export DebugInfoLevel, > otherwise it wouldn't compile with the other GHC versions. > > Does GHC do something special with Cabal nowadays when it's no longer tied > to GHC? > > Is it because the Cabal-1.22.0.0 bundled with ghc is now different to the Cabal-1.22.0.0 in github? I get the same error compiling the master branch cabal-install with ghc-7.10.0-20141222. I think one solution is to increase the version number of Cabal in github (for 1.22 and master branches), and to make the latest cabal-install depend on this (i.e. Cabal>=1.22.0.1) since cabal-install 1.22 in github no longer works with the 'released' snapshot Cabal-1.22.0.0 in ghc. This fixes the error for ghc-7.10.0-20141222. ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: The bootstrap.sh script has to go
I have a pull request here for review: https://github.com/haskell/cabal/pull/2312 On 1 January 2015 at 18:43, Johan Tibell wrote: > See https://github.com/haskell/cabal/issues/2310 for a continuation of > the sad bootstrap.sh saga. > > On Thu, Jan 1, 2015 at 6:43 AM, Herbert Valerio Riedel > wrote: > >> On 2014-12-30 at 21:23:19 +0100, Jake Wheat wrote: >> >> [...] >> >> > Simplify the bootstrap.sh process: >> > >> > * always use a fixed set of versions of packages for the dependencies >> >> For me, the primary use-case of `bootstrap.sh` is to be able to build a >> matching `cabal-install` executable for a given major GHC version w/o >> requiring having an existing cabal-install executable compatible w/ the >> GHC version I'm trying to bootstrap cabal-install with. (If I had an >> older `cabal-install` executable, I would use that to bootstrap the new >> one) >> >> So, if a given cabal-install's bootstrap.sh would only support >> bootstrapping via its associated GHC major version >> (e.g. cabal-install-1.22.x would require GHC 7.10.x) then I guess the >> bootstrap.sh wouldn't need to perform any significant package version >> resolving, and could just use such a single fixed set of versions (and >> preferably in a sandbox to ignore any user pkg-db) as you seem to >> propose. >> >> >> Alternatively, GHC could start bundling cabal-install, which would IMHO >> eliminate the need for a bootstrap.sh in the first place (but we had >> that discussion already, and it would also require to pull >> cabal-install's dependencies into the GHC distribution, while OTOH GHC >> is trying to avoid acquiring additional build dependencies...) >> >> Cheers, >> hvr >> > > ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: The bootstrap.sh script has to go
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 mess. 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. ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
tweaks to cabal-install bootstrap.sh
Hello, I've made some tweaks to the bootstrap.sh here: https://github.com/JakeWheat/cabal/tree/bootstrap-tweaks 1. It avoids downloading the additional haskell package tarballs if these tarballs are already present in the current directory. Motivation: easily install on machines not connected to the internet, and make install more robust against local internet connection problems (we have a lot of these). 2. The SCOPE_OF_INSTALLATION variable use is slightly changed to allow installing cabal-install executable without either using or altering the user's package database, or replacing any cabal-install executable which they already have. Example: ghc-pkg init /home/jake/test_cabal/ SCOPE_OF_INSTALLATION='--global --package-db=/home/jake/test_cabal/packagedb' PREFIX=/home/jake/test_cabal/prefix ./bootstrap.sh Is it possible to put these changes into the main cabal repo? If there are some changes which would make the patch acceptable then please let me know. Also, is there a simpler way to meet these goals which I missed? Thanks, Jake Wheat ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
