This project is mirrored from https://github.com/haskell/Cabal.
Pull mirroring updated .
- 19 Sep, 2016 11 commits
-
-
Edward Z. Yang authored
In Cabal 1.22.5.0, the semantics of --disable-profiling/--enable-profiling depend on ordering (because there is a hack that operates by looking at the current flag assignment and doing something). In particular, if I specify --enable-library-profiling --disable-profiling, I end up with library profiling DISABLED. The fix is that we NEVER pass --enable-profiling or --disable-profiling to Cabal. At the moment, and according to my historical analysis, Cabal ONLY uses configProf to affect the effective library/executable profiling, which means that anything we do with --enable-profiling, we can do using the library/executable profiling individually. Since these are always flags for the versions of Cabal library we support, we will get order invariance. Historical versions have varied on whether or not setting executable profiling implies library profiling, but if we set both explicitly this change in behavior doesn't matter. This patch is difficult to test because the bad profiling flags can't be induced on an inplace build. I tested by hand by building a package that depended on 'distributive' by hand. Fixes #3790. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Print profiling status when displaying install plan.
-
Edward Z. Yang authored
Use enabledBuildInfos rather than allBuildInfo
-
Edward Z. Yang authored
CC @hvr Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Add a new field to solver Done nodes, and simplify Explore.exploreLog.
-
Duncan Coutts authored
Give more informative error when ghc-pkg dump fails.
-
Brendan Hay authored
Track cabal.project provenance for error reporting
-
bardur.arantsson authored
Renumber flags version numbers in 'filterConfigureFlags'.
-
Herbert Valerio Riedel authored
"Secure" cabal repositories use a new extended & incremental `01-index.tar`. In order to avoid issues resulting from clobbering new/old-style index data, we save them locally to different names. With this patch, secure repos generate/update the files below on `cabal update` - `01-index.cache` - `01-index.tar` - `01-index.tar.gz` - `01-index.tar.idx` - `mirrors.json` - `root.json` - `snapshot.json` - `timestamp.json` ...while the legacy codepaths for non-secure repos operate on the files - `00-index.cache` - `00-index.tar` - `00-index.tar.gz` - `00-index.tar.gz.etag` This way the old/new codepaths don't interfere with each other anymore. Note: The format of `01-index.cache` file will be extended by the upcoming `--index-state` feature This trivially fixes #3854
-
Herbert Valerio Riedel authored
doc: "Local versus external packages" intro paragraph bad contrast [skip ci]
-
John Ericson authored
I believe it's "per-project" vs "cached across *projects*" not "...across *packages*"
-
- 18 Sep, 2016 14 commits
-
-
kristenk authored
-
kristenk authored
-
kristenk authored
-
Herbert Valerio Riedel authored
This was introduced accidentally via b083151f /cc @ezyang
-
Brendan Hay authored
- Excludes provenance from all roundtrip tests - Inserting explicit provenance when read from file - Special cases for bad package errors arising from implicit project configuration
-
Edward Z. Yang authored
Previously, the code was inconsistent on whether or not flags_x_y_z indicated that these flags could be used up to version x.y.z, or should be used prior to x.y.z. This commit picks the LATTER and renames everything consistently this way. The bonus is that now the names match up with the conditionals. Yay. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
In many places, we incorrectly used allBuildInfo, which returns all BuildInfos that are buildable, and not necessarily the ones we are actually going to *build*. This used to "mostly do the right thing" because we literally edited the PackageDescription to nub out things, so you wouldn't see non-enabled components anyway. However when I added support for per-component configure, I stopped editing the PackageDescription, which meant all of these uses were wrong. So, I updated them to do the right thing. Note that there are still uses of allBuildInfo in Check, but that probably requires a closer look. Fixes #3847. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Mikhail Glushenkov authored
[ci skip]
-
Edward Z. Yang authored
In the previous documentation for 'ComponentEnabledSpec', I claimed that enabled components were buildable, as well as requested by the user. In the course of working on #3847, however, I realized that I hadn't actually *checked* that the component was buildable anywhere. In particular, the 'ComponentDisabled' reason was *never used*. This mostly didn't cause problems, however, because when we 'flattenPD' all non-buildable components get deleted, so you basically never actually have a non-buildable 'Component'. But it still seemed a bit silly, so I fixed it by doing this: 1) I introduce a new concept of a component being requested, which captures the use of --enable-tests and friends. This does NOT imply buildability. Renamed ComponentEnabledSpec to ComponentRequestedSpec 2) A component is enabled if it is requested and buildable. If you give me a Component and a ComponentRequestedSpec I can tell you if it's enabled. However, if you give me a ComponentName I can't, because I have no idea if it's buildable. 3) Stopped reexporting ComponentRequestedSpec from Distribution.Simple.LocalBuildInfo 4) Added a test for attempting to specify a non-buildable component as a target. The test is accepting suboptimal output at the moment, see #3858. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Implement cabal new-build --only-dependencies
-
Edward Z. Yang authored
Add examples to help text for reconfigure command
-
Edward Z. Yang authored
When debugging #3827, I wished I could see what the profiling status of all packages in our install plan was. This patch outputs this information, by printing the *configure flag* we would have passed to configure. In an ideal world, we'd print exactly the configure flags we actually pass in practice. But this is not so great because the flag lists tend to be really long. So we pare it down in the following ways: 1. Not all flags are output: only a selected few. In this patch, it's just enabling/disabling profiling flags, but we could add more. 2. If we have Flag False for profiling, we will actually explicitly pass --disable-profiling to the configure script. But it's not so good to output that to the user. So 'nubFlag' lets us drop the flag, if omitting it would have the same effect as specifying it. Figuring that out is a little tricky though. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
- 17 Sep, 2016 2 commits
-
-
ttuegel authored
-
Mikhail Glushenkov authored
Revive GHC 7.4 support and revise the GHC compatibility window for the Cabal library
-
- 16 Sep, 2016 13 commits
-
-
Edward Z. Yang authored
Even more docs beautification
-
Leonid Onokhov authored
[ci skip]
-
Leonid Onokhov authored
[ci skip]
-
Leonid Onokhov authored
Is now rendered as object description, and can have attached meta. [ci skip]
-
Leonid Onokhov authored
And also how reference page is build [ci skip]
-
Mikhail Glushenkov authored
-
Mikhail Glushenkov authored
[ci skip]
-
Leonid Onokhov authored
[ci skip]
-
Leonid Onokhov authored
Reference index shows fields and flags for project.cabal and fields for pkgname.cabal [ci skip]
-
Leonid Onokhov authored
And converted nix-local-build.rst to use it [ci skip]
-
Leonid Onokhov authored
[ci skip]
-
Leonid Onokhov authored
[ci skip]
-
Leonid Onokhov authored
[ci skip]
-