Re: Gearing up for a 1.18 release
I definitely think impl(ghc) should cover GHCJS, as it effectively just is a GHC backend (even if not part of GHC). Doing otherwise would be a bit like having impl(ghc) be false when compiling with -fllvm IMHO. The value of GHCJS is that it's supposed to be able to compile most existing packages as-is. Just my two cents. :-) On Sun, Aug 25, 2013 at 6:53 PM, Luite Stegeman stege...@gmail.com wrote: I think we should definitely fix the packages, not put a hack in Cabal. In the latest hackage archive, there are 462 packages that use the impl(ghc) flag, including lots of very common packages. For example binary: if impl(ghc = 7.2.1) cpp-options: -DGENERICS other-modules: Data.Binary.Generic if impl(ghc = 7.6) -- prior to ghc-7.4 generics lived in ghc-prim build-depends: ghc-prim Is there a generic way to do this without impl ghc checks? Otherwise all these impl(ghc = x) flag checks have to be changed to impl(ghc = x) || impl(ghcjs = y), not something I'd be looking forward to... Also I personally don't really see it as a hack (of course I'm biased since I've been using it for a while). It just allows you to specify that compiler x is based on compiler y, so that unless explicitly queried otherwise you can assume that flags for 'y' hold for 'x'. luite ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: Gearing up for a 1.18 release
To be honest I think that's a much bigger hack than what I originally proposed. The point of the sub/super compiler CompilerId change is that both parts can have their own version range. For example GHCJS is currently at version 0.1.0, GHC at 7.6. While currently GHCJS can only be built against HEAD, that could change in the future (we used to have a version compatible with both 7.4 and 7.6), and one could want checks like this: impl(ghcjs = 0.1) impl(ghc 7.10) I think this could also come in handy with Roman's haskell-suite compiler flavour, which makes it easy to make customized compilers. If you make something based on GHC it would be useful to be able to specify that, so you can support packages that depend on impl(ghc) checks. With this CompilerId change, that can be implemented for the HaskellSuite flavour by just giving the user a way to specify the compiler name/version. If there's a way to achieve this without changing CompilerId, that would be great. As for the CompilerId change itself: There are 11 packages on hackage that appear to use the CompilerId constructor (archlinux, cab, cabal-debian, cabal-db, cabal2nix, cabal-ghci, cabal-install-bundle, cblrepo, ghc-mod, hackport, hoogle) I'd be happy to send all of them a pull req. For other projects (not on hackage), I think that with some comments/Haddock the CompilerId type they can be quickly guided towards the right change (usually ignoring the field or adding Nothing) luite On Mon, Aug 26, 2013 at 3:39 PM, Johan Tibell johan.tib...@gmail.comwrote: Lets change the implementation of `impl` itself then to have ghc == ghcjs = True. This way the special casing is at least localized and not all users of the CompilerId data type need to care. Are there any other such checks that need to be adjusted? On Mon, Aug 26, 2013 at 7:39 AM, Dag Odenhall dag.odenh...@gmail.com wrote: I definitely think impl(ghc) should cover GHCJS, as it effectively just is a GHC backend (even if not part of GHC). Doing otherwise would be a bit like having impl(ghc) be false when compiling with -fllvm IMHO. The value of GHCJS is that it's supposed to be able to compile most existing packages as-is. Just my two cents. :-) On Sun, Aug 25, 2013 at 6:53 PM, Luite Stegeman stege...@gmail.com wrote: I think we should definitely fix the packages, not put a hack in Cabal. In the latest hackage archive, there are 462 packages that use the impl(ghc) flag, including lots of very common packages. For example binary: if impl(ghc = 7.2.1) cpp-options: -DGENERICS other-modules: Data.Binary.Generic if impl(ghc = 7.6) -- prior to ghc-7.4 generics lived in ghc-prim build-depends: ghc-prim Is there a generic way to do this without impl ghc checks? Otherwise all these impl(ghc = x) flag checks have to be changed to impl(ghc = x) || impl(ghcjs = y), not something I'd be looking forward to... Also I personally don't really see it as a hack (of course I'm biased since I've been using it for a while). It just allows you to specify that compiler x is based on compiler y, so that unless explicitly queried otherwise you can assume that flags for 'y' hold for 'x'. luite ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: Gearing up for a 1.18 release
I'd like for Duncan to comment on this. If there's a way to achieve this without changing CompilerId, that would be great. As for the CompilerId change itself: There are 11 packages on hackage that appear to use the CompilerId constructor (archlinux, cab, cabal-debian, cabal-db, cabal2nix, cabal-ghci, cabal-install-bundle, cblrepo, ghc-mod, hackport, hoogle) I'm not worried about these packages, but about the Cabal code base itself. On Mon, Aug 26, 2013 at 1:00 PM, Luite Stegeman stege...@gmail.com wrote: To be honest I think that's a much bigger hack than what I originally proposed. The point of the sub/super compiler CompilerId change is that both parts can have their own version range. For example GHCJS is currently at version 0.1.0, GHC at 7.6. While currently GHCJS can only be built against HEAD, that could change in the future (we used to have a version compatible with both 7.4 and 7.6), and one could want checks like this: impl(ghcjs = 0.1) impl(ghc 7.10) I think this could also come in handy with Roman's haskell-suite compiler flavour, which makes it easy to make customized compilers. If you make something based on GHC it would be useful to be able to specify that, so you can support packages that depend on impl(ghc) checks. With this CompilerId change, that can be implemented for the HaskellSuite flavour by just giving the user a way to specify the compiler name/version. If there's a way to achieve this without changing CompilerId, that would be great. As for the CompilerId change itself: There are 11 packages on hackage that appear to use the CompilerId constructor (archlinux, cab, cabal-debian, cabal-db, cabal2nix, cabal-ghci, cabal-install-bundle, cblrepo, ghc-mod, hackport, hoogle) I'd be happy to send all of them a pull req. For other projects (not on hackage), I think that with some comments/Haddock the CompilerId type they can be quickly guided towards the right change (usually ignoring the field or adding Nothing) luite On Mon, Aug 26, 2013 at 3:39 PM, Johan Tibell johan.tib...@gmail.com wrote: Lets change the implementation of `impl` itself then to have ghc == ghcjs = True. This way the special casing is at least localized and not all users of the CompilerId data type need to care. Are there any other such checks that need to be adjusted? On Mon, Aug 26, 2013 at 7:39 AM, Dag Odenhall dag.odenh...@gmail.com wrote: I definitely think impl(ghc) should cover GHCJS, as it effectively just is a GHC backend (even if not part of GHC). Doing otherwise would be a bit like having impl(ghc) be false when compiling with -fllvm IMHO. The value of GHCJS is that it's supposed to be able to compile most existing packages as-is. Just my two cents. :-) On Sun, Aug 25, 2013 at 6:53 PM, Luite Stegeman stege...@gmail.com wrote: I think we should definitely fix the packages, not put a hack in Cabal. In the latest hackage archive, there are 462 packages that use the impl(ghc) flag, including lots of very common packages. For example binary: if impl(ghc = 7.2.1) cpp-options: -DGENERICS other-modules: Data.Binary.Generic if impl(ghc = 7.6) -- prior to ghc-7.4 generics lived in ghc-prim build-depends: ghc-prim Is there a generic way to do this without impl ghc checks? Otherwise all these impl(ghc = x) flag checks have to be changed to impl(ghc = x) || impl(ghcjs = y), not something I'd be looking forward to... Also I personally don't really see it as a hack (of course I'm biased since I've been using it for a while). It just allows you to specify that compiler x is based on compiler y, so that unless explicitly queried otherwise you can assume that flags for 'y' hold for 'x'. luite ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: Gearing up for a 1.18 release
I'm not worried about these packages, but about the Cabal code base itself. The Cabal code base hardly creates CompilerId directly, in almost all cases the change is ignoring the third field. This is where CompilerId is created: All existing flavours add Nothing, 6x one-line change: - https://github.com/ghcjs/cabal/commit/ce3c18aedbc4fbf58b150f10690aa5dca6ab0d72#L15R109 Distribution.PackageDescription.Check uses it, but only for checking that the base range is bounded, not with a real compiler, but with buildCompiler with no version: - https://github.com/ghcjs/cabal/commit/ce3c18aedbc4fbf58b150f10690aa5dca6ab0d72#L2L1240 buildCompilerId uses it (buildCompilerId is never used in Cabal, cabal-install and hackage), a better change would be to find the subcompiler if buildCompilerFlavor is GHCJS, but just adding Nothing makes it do the right thing for all existing compilers: - https://github.com/ghcjs/cabal/commit/ce3c18aedbc4fbf58b150f10690aa5dca6ab0d72#L1R137 The other changes are the direct intended changes: Updated flag resolution, parsing/printing CompilerId, and getting the shared library filename from a CompilerId ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Cabal-1.18.0 and cabal-install-1.18.0 release candidates (please test)
Hi all, We're close to a new release of Cabal/cabal-install and I'd appreciate some help in testing the new release. To install the release candidate, simply run: cabal install http://johantibell.com/files/Cabal-1.18.0.tar.gz http://johantibell.com/files/cabal-install-1.18.0.tar.gz Please try on different OSes if you have several available. Report bugs at https://github.com/haskell/cabal/issues *Things to try* This is not a complete list of new features (and bugs fixed)! *Sandboxing* Sandboxes help prevent dependency hell by having each project you're working on use a separate package database to install its dependencies in. Try it out on one of your projects like so: cd my-pkg cabal sandbox init # only once cabal install --only-dependencies cabal configure cabal build *GHCi support* The new cabal repl commands lets you load up your library inside GHCi without lots of command line fiddling. Just run cabal repl instead of cabal build and play around without your library. *Known issues to be fixed before release* https://github.com/haskell/cabal/issues/1439 Cheers, Johan ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
