GitLab

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>

Print profiling status when displaying install plan.

Use enabledBuildInfos rather than allBuildInfo

CC @hvr

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Add a new field to solver Done nodes, and simplify Explore.exploreLog.

Give more informative error when ghc-pkg dump fails.

Track cabal.project provenance for error reporting

Renumber flags version numbers in 'filterConfigureFlags'.

"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

doc: "Local versus external packages" intro paragraph bad contrast

[skip ci]

I believe it's "per-project" vs "cached across *projects*" not "...across *packages*"

This was introduced accidentally via
b083151f

/cc @ezyang

- Excludes provenance from all roundtrip tests
- Inserting explicit provenance when read from file
- Special cases for bad package errors arising from
  implicit project configuration

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>

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>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

[ci skip]

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>

Implement cabal new-build --only-dependencies

Add examples to help text for reconfigure command

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>

Revive GHC 7.4 support and revise the GHC compatibility window for the Cabal library

Even more docs beautification

[ci skip]

[ci skip]

Is now rendered as object description, and can have attached meta.

[ci skip]

And also how reference page is build

[ci skip]

[ci skip]

[ci skip]

Reference index shows fields and flags for project.cabal and fields for
pkgname.cabal

[ci skip]

And converted nix-local-build.rst to use it

[ci skip]

[ci skip]

[ci skip]

[ci skip]