tweaks to cabal-install bootstrap.sh

2014-09-28 Thread Jake Wheat
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


Re: The bootstrap.sh script has to go

2014-12-30 Thread Jake Wheat
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


Re: The bootstrap.sh script has to go

2015-01-02 Thread Jake Wheat
I have a pull request here for review:
https://github.com/haskell/cabal/pull/2312

On 1 January 2015 at 18:43, Johan Tibell johan.tib...@gmail.com 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 h...@gnu.org
 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: Cabal 1.22 RC ready to test

2015-01-03 Thread Jake Wheat
On 3 January 2015 at 15:05, Johan Tibell johan.tib...@gmail.com 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


Bootstrap.hs

2015-01-10 Thread Jake Wheat
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