Upstream changes #4

Closed
wants to merge 84 commits into
from

Conversation

Projects
None yet
@ghost

ghost commented Oct 2, 2012

  • base >= 4
  • old-time -> time

merijn and others added some commits Aug 30, 2012

Fixed configure script location detection of autoconf.
The autoconf generated configure script tries to automatically determine the
location of the configure script. If the name (argv[0]) of the configure script
does not include a path separator autoconf will *first* scan the path for a
file named "configure" before defaulting to the current directory.

Cabal previously called configure by doing "sh configure" this will result in
it finding any files named "configure" in the path and using the location of
that file as the basedir to look for (amongst other things) C sources. The
result is that any C sources in the unpacked cabal directories are not found,
resulting in configure/build failures for all such packages (e.g. unix-time)
and all packages depending on those.

Changing cabal to call "sh ./configure" will avoid this behaviour, the presence
of a path separator causes autoconf to default to checking the current
directory *first*.
Make compatible with `network-2.4` API
The specific API change in `relativeTo` this changeset
compensates for has been introduced in

 haskell/network@4a3fdef
Merge pull request #1044 from hvr/network24
Make compatible with `network-2.4` API
Fall back to looking on the path for ghc-related tools
This fixes things for situations such as where hsc2hs is in /usr/bin
but ghc is in /usr/local/bin, where previously we'd get:
  cabal: The program hsc2hs is required but it could not be found
On install, update the .cabal file with the one from the index
This allows us to make minor changes to packages after they have been
released, without changing the package .tar.gz file. We already keep
the .cabal file outsite the package in the index and use it for
dependency planning. This already lets us do fixes such as making
dependency constraints tighter. Currently we cannot make dep
constraints more relaxed however, since the original .cabal file is
the one used when we get to the actual configure step.

So with this change, we now use the updated .cabal file for the
configure and build too. So there's more fixes we can do post-release.
In particlar, in combination with easier editing on hackage, this
should help us address the problems around the PVP and open or closed
version constraints. It should allow a system of conservative upper
bounds, but allow editing them when new versions of deps are released
and we find that they happen to work fine.
Extend the unpack command for the .cabal file updating
By default, "cabal unpack blah" will also update the .cabal file with
the one from the index, so it's consistent with what you get via
cabal install. Also added a --pristine flag so you can get the original
tarball without the updated .cabal file.
On install, update the .cabal file with the one from the index
(patch manually merged into the cabal-1.16 branch)

This allows us to make minor changes to packages after they have been
released, without changing the package .tar.gz file. We already keep
the .cabal file outsite the package in the index and use it for
dependency planning. This already lets us do fixes such as making
dependency constraints tighter. Currently we cannot make dep
constraints more relaxed however, since the original .cabal file is
the one used when we get to the actual configure step.

So with this change, we now use the updated .cabal file for the
configure and build too. So there's more fixes we can do post-release.
In particlar, in combination with easier editing on hackage, this
should help us address the problems around the PVP and open or closed
version constraints. It should allow a system of conservative upper
bounds, but allow editing them when new versions of deps are released
and we find that they happen to work fine.
Extend the unpack command for the .cabal file updating
By default, "cabal unpack blah" will also update the .cabal file with
the one from the index, so it's consistent with what you get via
cabal install. Also added a --pristine flag so you can get the original
tarball without the updated .cabal file.
Always use either -static or -dynamic when compiling with GHC
-static is no longer necessarily the default
Fix building cabal-install with ghc-6.12 and older
Fall back to using serial rather job control for base < 4.3.
So this means if you build caba-install with ghc-6.12 or older
then the -j flag will do nothing, it'll still run serially.

BTW, if anyone wants to build cabal-install using a Haskell impl
with no support for concurrency then they can use the same trick.
(The serial and parallel job control impls deliberately share the
same interface.)
Conditionally turn on dynamic-executable by default
If the compiler builds dynamic things by default, then so does Cabal.
Disable setting the jobs: $nprocs line in default ~/.cabal config
It breaks for fresh installs with users who have Cabal-1.6.0
rather than Cabal-1.6.0.1, ie users of ghc-7.6.1.

23Skidoo and others added some commits Sep 13, 2012

Bump network dependency in bootstrap.sh to 2.3.1.1
network-2.3.1.0 does not build on Windows with GHC 7.6.1.
When dynamic-by-default, build the dynamic library first
This is particularly important when TH is being used, as we need the
dynamic library built before the other ways try to do TH.
Actually implement the 'sandbox-init' command.
Additionally, change the search location for the package environment file to the
project directory instead of the sandbox directory.
Replace fragile GHC manual section references by urls
This replaces the GHC/Hugs manual references in the Haddock comments
for the `Language.Haskell.Extension.Extension` enum constructors, as
in

```haskell
  -- | [GHC &#xa7; 7.6.3.4] Allow overlapping class instances,
  -- provided there is a unique most specific instance for each use.
  OverlappingInstances
```

which urls pointing directly to the section containing further
documentation (assuming the urls are more immune to section
reorderings), e.g.:

```haskell
  -- | Allow overlapping class instances, provided there is a unique
  -- most specific instance for each use.
  --
  -- * <http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#instance-overlap>
     OverlappingInstances
```
Merge pull request #1072 from hvr/lang-ext
Replace fragile GHC manual section references by urls
Merge pull request #1021 from merijn/master
Fix for autoconf misbehaviour caused by cabal
Add a couple of new language extension flags known by GHC 7.[46]
Specifically,

 - `CApiFFI`
 - `DataKinds`
 - `DefaultSignatures`
 - `DeriveGeneric`
 - `InstanceSigs`
 - `InterruptibleFFI`
 - `LambdaCase`
 - `MonadComprehensions`
 - `MultiWayIf`
 - `ParallelArrays`
 - `PolyKinds`
 - `TraditionalRecordSyntax`
 - `Unsafe`

This addresses #1050
Merge pull request #1073 from hvr/lang-exts-ghc76
Add a couple of new language extension flags known by GHC 7.[46]
Fix error messages with "cabal update" -> "hackport update" Same fix …
…as marty.rosenberg@gmail.com once did for cabal-install-0.8.2, which we now are replacing.
disable hackage's preferred-versions (as we don't use it when merge e…
…builds)

hackage.haskell.org/00-index.tar contains preferred-versions for some interesting
packages. For now it's 'base-3'.

Otherwise depends generated by hackport differ from ones pulled by ./Setup.hs.
cabal/cabal-install: renamed D.C.Exception -> D.C.ExceptionCI to avoi…
…d clash with Cabal's one

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
@cnd

This comment has been minimized.

Show comment
Hide comment
@cnd

cnd Dec 18, 2012

Member

close it.

Member

cnd commented Dec 18, 2012

close it.

@trofi

This comment has been minimized.

Show comment
Hide comment
@trofi

trofi May 8, 2016

Member

I've missed that completely. My apologies!

Closed.

Member

trofi commented May 8, 2016

I've missed that completely. My apologies!

Closed.

@trofi trofi closed this May 8, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment