This project is mirrored from Pull mirroring updated .
  1. 06 Mar, 2015 1 commit
  2. 04 Mar, 2015 2 commits
  3. 01 Mar, 2015 2 commits
  4. 25 Feb, 2015 1 commit
  5. 23 Feb, 2015 2 commits
  6. 20 Feb, 2015 1 commit
  7. 28 Jan, 2015 2 commits
  8. 27 Jan, 2015 3 commits
  9. 19 Jan, 2015 2 commits
  10. 18 Jan, 2015 4 commits
  11. 17 Jan, 2015 1 commit
  12. 14 Jan, 2015 1 commit
    • capsjac's avatar
      add Android OS · 058959a4
      capsjac authored
      Though Android OSs are based on Linux, they have very unique APIs that desktop OSs do not have.
      e.g. Bonic C lib, /dev/binder,, lots of Java native APIs, etc.
      Plus, Android has own different directory structures, environment variables, application starting scheme and security.
      I think it seems better choise to distinguish mobile platforms from desktop OSs.
  13. 13 Jan, 2015 3 commits
  14. 12 Jan, 2015 3 commits
  15. 10 Jan, 2015 1 commit
  16. 08 Jan, 2015 1 commit
    • ttuegel's avatar
      D.Compat.Binary: backport binary generics to binary-0.5 · c650e347
      ttuegel authored
      GHC generics are used to derive binary instances for types appearing
      in the persistent build config, which requires GHC >= 7.2 and
      binary >= 0.7. Unfortunately, GHC < 7.8 ships with binary == 0.5.*.
      The missing module is Data.Binary.Generics, which we have copied from
      binary- to Distribution.Compat.Binary.Generics. To provide
      generic implementations for the Binary class, we also have to provide
      our own implementation, which is copied from binary- to
      Distribution.Compat.Binary.Class. The interface required by Cabal is
      exported from Distribution.Compat.Binary. This is only done if
      bootstrapping Cabal with GHC < 7.8 or if binary >= 0.7 is not available,
      otherwise Distribution.Compat.Binary simply re-exports Data.Binary.
  17. 05 Jan, 2015 1 commit
  18. 03 Jan, 2015 2 commits
  19. 19 Dec, 2014 4 commits
  20. 18 Dec, 2014 3 commits
    • barmston's avatar
      cabal install can be used inside a cabal exec environment · 0a4aed40
      barmston authored
      Inside a cabal exec environment cabal should be configured to always use the
      correct environment. When there is a sandbox this is addressed by setting the
      CABAL_SANDBOX_CONFIG environment variable.
      However GHC is configured to use the correct package database through setting
      the GHC_PACKAGE_PATH environment variable to include the sandbox database. The
      Cabal library previously refused to operate when GHC_PACKAGE_PATH is set in
      order to avoid having a different view of the package databases to GHC.
      In the case of a cabal exec environment being loaded for a cabal sandbox, it
      is safe to allow the use of GHC_PACKAGE_PATH as it is being used to ensure
      that GHC uses the same package database as cabal does.
      A check is made that GHC_PACKAGE_PATH matches the value that cabal exec set it
      to. If it does use of GHC through cabal is permitted.
      Fixes #1800
    • ttuegel's avatar
    • ttuegel's avatar
      Enable library profiling when profiling executables · 6b631745
      ttuegel authored
      It doesn't make any sense to do a profiling build of an executable if
      the library doesn't have a profiled build! The option
      --enable-executable-profiling is changed to --enable-profiling to
      reflect that it is now a global flag. The old option is still recognized
      (for now).