Added `--all` (`--haddock-all`) switches for compatibility with
`haddock` command.  `--haddock-all` alias is added, since that's what is
suggested by some warning messages.

Fixes #10051

Add a flag to disable the hard requirement on the
build-tools-(depends) declared on the Cabal package.

When this flag is enabled (--ignore-build-tools), a build-tool which
can't be found does not block compilation.

Fixes #10061

When no pkg-config program was found, cabal would
claim that the package is not in the db, instead
of telling clearly that no pkg-config was found at
all.

* Changelogs for 3.12.1.0 (#10124)

* changelog for 3.12.1.0

* fixup! changelog for 3.12.1.0

* fixup! Changelogs for 3.12.1.0

Co-authored-by: Artem Pelenitsyn <a.pelenitsyn@gmail.com>

* fixup! changelog for 3.12.1.0

* fixup! changelog for 3.12.1.0

* fixup! Changelogs for 3.12.1.0

Co-authored-by: ffaf1 <fa-ml@ariis.it>

* fixup! Changelogs for 3.12.1.0

* fixup! Changelogs for 3.12.1.0

* fixup! Changelogs for 3.12.1.0

---------

Co-authored-by: Artem Pelenitsyn <a.pelenitsyn@gmail.com>
Co-authored-by: ffaf1 <fa-ml@ariis.it>
(cherry picked from commit 2067ed19)

# Conflicts:
#	release-notes/Cabal-3.12.0.0.md

* fixup! Changelogs for 3.12.1.0 (backport #10124)

---------

Co-authored-by: brandon s allbery kf8nh <allbery.b@gmail.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

New options for cabal.project and ./Setup interface:

* `profiling-shared`: Enable building profiling dynamic way
* Passing `--enable-profiling` and `--enable-executable-dynamic` builds
  profiled dynamic executables.

Support for using `profiling-shared` is guarded behind a constraint
which ensures you are using `Cabal >= 3.13`.

In the cabal file:

* `ghc-prof-shared-options`, for passing options when building in
  profiling dynamic way

Other miscellenious fixes and improvements

* Some refactoring around ways so that which
  ways we should build for a library, foreign library and executable is
  computed by the `buildWays` function (rather than ad-hoc in three
  different places).

* Improved logic for detecting whether a compiler supports compiling
  a specific way. See functions `profilingVanillaSupported`,
  `dynamicSupported`, `profilingDynamicSupported` etc
  These functions report accurate infomation after ghc-9.10.1.

* Fixed logic for determining whether to build shared libraries. (see
  #10050)
  Now, if you explicitly enable `--*-shared`, then that will always take
  effect. If it's not specified then `--enable-executable-dynamic` will
  turn on shared libraries IF `--enable-profiling` is not enabled.

* Remove assumption that dynamically linked compilers can build dynamic
  libraries (they might be cross compilers.

* Query the build compiler to determine which library way is necessary
  to be built for TH support to work.
  (rather than assume all compilers are dynamically linked)

* An extensive test which checks how options for `./Setup` and
  `cabal-install` are translated into build ways.

Fixes #4816, #10049, #10050

* Add MHS as a recognized compiler.

* Add Changelog entry

* Add comment.

* Update checksums.

* Update more checksums.

---------

Co-authored-by: Lennart Augustsson <lennart.augustsson@epicgames.com>

This commit implements the Configure build-type in terms of Hooks,
when build-type: Hooks is available (for Cabal >= 3.13).

This moves Configure away from an implementation in terms of UserHooks,
i.e. away from the Custom build-type.

Issue #10063 points out that cabal exits before the external command
has finished executing. This was a simple oversight to not
waitForProcess on the result of calling createProcess.

This also points out the flaw that there isn't a way for external
commands to signal failure, so we now also propagate the exit code from
the external process.

Fixes #10063

* add the applicable new (versions 9.2 - 9.10) GHC flags to normaliseGhcArgs

Actionable flags are:
- fdiagnostics-as-json (changes the format GHC outputs its diagnostics)
- fprint-error-index-lists (changes the way GHC displays compile time)
- fbreak-points (enables/disables break-points in GHCi)
- dipe-stats (dumps information about which info tables have IPE
  information)
- ffamily-application-cache (only changes the speed of the compiler)
- fprint-redundant-promotion-ticks
- show-error-context
- unoptimized-core-for-interpreter (only applies to GHCi)

* [chore] correct the flag names and add a FUTUREWORK

Currently the options `--program-{prefix,suffix}` for cabal install
affects the name of the file in the install directory *and* the
executable name in the store. The installation fails:

- If using `--install-method=symlink`, the *target* of the symlink is
  not affected by the affix options and it results in an invalid symlink.
- If using `--install-method=copy`, the copy fails because the source
  is not found.

Another issue is that it affects the computation of the hash of the
build directory in the store, resulting in needless rebuild when using
successively different affix options.

Fixed by making the name of the executable in the store canonical, i.e.
always ignoring the program affix options.

Added a test for all the combinations of `--install-method` and program
affixes options.

We no longer define the `__HADDOCK_VERSION__` macro when invoking GHC
through Haddock, since doing so essentially guarantees recompilation
during documentation generation.

We audited all uses of `__HADDOCK_VERSION__` in hackage, ensuring there
was a reasonable path forward to migrate away from using
`__HADDOCK_VERSION__` for each, while generating the same documentation
as it did before.

If you are a user of `__HADDOCK_VERSION__`, please take a look at the
discussion in https://github.com/haskell/cabal/pull/9177 and reach out
to us if your use case is not covered.

Reverts the version-cpp flag introduced in the previous commit to avoid
a workaround. Instead, we get rid of the problem (`__HADDOCK_VERSION__`) at its root.

See the discussion in #9177

Haddock no longer writes compilation files by default, so we do not need to pass
tmp dirs for `-hidir`, `-stubdir`, and `-odir` via `--optghc`. Indeed, we do not
*want* to do so, since it results in recompilation for every invocation of
Haddock via Cabal. This commit stops this from happening for haddock versions >=
2.28 (when Hi Haddock was introduced).

This commit also stops the default definition of the `__HADDOCK_VERSION__` macro
when invoking GHC through haddock. Since a very limited set of users may still
depend on this macro, we introduce the `--haddock-version-cpp` flag and
`haddock-version-cpp:` cabal.project field, which enable the definition of
the `__HADDOCK_VERSION__` macro when invoking GHC through Haddock. This will
almost guarantee recompilation during documentation generation due to the macro
definition.

This commit also renames the `--haddock-lib` flag to `--haddock-resources-dir`
(and `haddock-lib:` cabal.project field to `haddock-resources-dir:`), and adds
this flag to the users guide since it was missing an entry. This also allows us
to add this field to `cabal-install:test:integration-tests2`, since it is no
longer ambiguous with the `--lib` flag.

This commit also causes `documentation: true` or `--enable-documentation` to
imply `-haddock` for GHC.

Also, since Haddock >= 2.29 is renaming `--lib` to `--resources-dir`, this
commit switches the flag provided to Haddock using a backwards compatible
condition based on the Haddock version.

Adds a changelog entry.

Disallowing whitespace while parsing target selectors incorrectly
disallows file targets with whitespace in the paths, which can issues
when users pass absolute paths.

fixes #8875

- Use real-life example from Cabal project in doctest

This makes Setup copy/install succeed if there's
nothing to do because the package doesn't contain
a library or executable.

This allows downstream users of Cabal to avoid having to
add workarounds for this edge case.

Resolves #6750

This patch reinstates the 'initialBuildSteps' function, as it is
used by stack in its implementation of the multi-repl feature.

A deprecation warning has been added to that function: calling it does
not suffice to prepare the sources for a package, as there are other
steps that one might also need to perform:

  - running pre-processors (such as alex/happy)
  - running pre-build hooks or custom logic (in build-type: Hooks
    or build-type: Custom or Configure)

Consumers wanting to prepare the sources of a package, e.g. in order to
launch a REPL session, are advised to run
`Setup repl --repl-multi-file=<fn>` instead.

Fixes #9856

* Add release notes for Cabal 3.12

Forwardport of #9785, #9908

Add changelog/release notes for Cabal 3.12 (#9785)

- generated with
     git log --pretty=oneline --no-color cabal-install-v3.10.1.0..HEAD > 3.12.prlog
- deduped
- stored WIP “release notes” file for future `cabal-install` release

3.12 changelogs updated (#9908)

* Update changelog for 3.12

(and for future WIP 3.12.1.0 cabal-install)

* Remove changelog.d files

* 3.12 changelog fixup (#9922)

* Incorporate Brandon’s suggestions

See #9920.

* Incorporate Artem’s suggestions

See #9920.

* Do not repeat yourself

* Fix whitespace

* Fix release notes grammar

See #9920.

This commit introduces a new build-type, Hooks. A package using this
build type should provide a SetupHooks.hs module which exports
a value `setupHooks :: SetupHooks`. This is intended to replace the
Custom setup type. This allows Cabal to have finer-grained information
about the build, instead of having an opaque Setup executable to invoke.

Tests include:

  - error when returning an invalid component diff in a
    per-component pre-configure hook
  - error when declaring pre-build rules whose dependency
    graph contains cycles
  - error when we cannot find a dependency of a pre-build rule
  - warning when there are pre-build rules that are declared but
    never demanded
  - correctness tests for SetupHooks, e.g. that
    pre-build rules are run in dependency order (see the
    `SetupHooksRuleOrdering` test)

- Use independent package name in doctest
- Add changelog entry
- Still use showOption when linked
- Typo, package is cabal-install-solver
- Rename showIsOrVs to showOptions
- Add linked doctests for showOptions

* Redesign 'cabal path' command to account for projects

Previously, `cabal path` was only able to query from the global
configuration file, e.g., `~/.cabal/config` or the XDG equivalent.
Adding support for cabal project is a huge boost to usability.

We take the foundations and turn them into `cabal v2-path` which takes
project configuration, such as `cabal.project` into account.
Note, the command is still named `cabal path`, but for the sake of
disambiguation, we refer to this new iteration of the command as `cabal
v2-path`.

In addition, we add support for multiple output formats, such as
key-value pairs and json.

The key-value pair output prints a line for each queried key and its
respective value:

    key1: value2
    key2: value2

If only a single key is queried, we print only the
value, for example:

    value1

The json output format is versioned by the cabal-install version which
is part of the json object.
Thus, all result objects contain at least the key "cabal-install-version".

We expand the `cabal v2-path` to also produce information of the
compiler that is going to be used in a `cabal build` or `cabal repl` invocation.
To do that, we rebuild the install plan and query for the configured
compiler program.
This is helpful for downstream tools, such as HLS, to figure out the GHC
version required to compile a project with.

We also add an exhaustive test suite for 'cabal path' cmd

We test that each query honours cabal.project files, cli parameters, and
is composable with the other query flags.

We extend the test output normalisers for ghc compiler location and
cabal-install version, as the 'cabal path' command outputs the exact ghc
and ghc-pkg location. In addition, the json output format is versioned
on the cabal-install version.

Currently, we query the cabal-install version on each test normalisation
run. This might be unnecessary expensive, and could be avoided by
introducing a 'cabalProgram' that specifies how the program version can
be found. This way, we can cache the version query.

Add '--cache-home' flag thats shows the cabal's cache root

Rename '--cache-dir' to the more correct '--remote-repo-dir'.

* Update 'cabal path' documentation

* Add changelog.d entry

---------

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

* Registered the NamedDefaults language extension

* Added changelog and Vim configuration lines

* Updated the expected hashes

---------

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

Per https://github.com/haskell/cabal/wiki/Updating-the-license-list
to version 3.23 (2024-02-08) of SPDX License List.

With this change to the solver message rendering, I also fix some bugs around project imports, adding tests for those cases. Reviewers asked that the Y-shaped import checks (using IORef) be made on a separate pull request. Removing those lead to cascading deletions.

- Regenerate expected .out files
- Show tree provenance of import constraint
- Add trimmed down PackageTests/VersionPriority
- Add changelog entry
- Use NonEmpty
- Fix check for cyclical import
- Use primes for next iteration
- Remove unused LANGUAGE pragmas
- Rename to projectConfigPathRoot
- Docs for ProjectConfigPath and showProjectConfigPath
- Renaming
- Add cyclical import tests with 1 and 2 hops in cycle
- Use full path for cyclical error message
- Expected output has project with full project path
- Add fullPath local function
- Project directory as FilePath, not Maybe FilePath
- Use (_, projectFileName) binding splitFileName
- Need full path to project parsing legacy
- Inline seenImports conversion
- Add cyclical checks with same file names and hops
- Add noncyclical tests that hop over folders
- Add a project testing skipping in and out of a folder
- Update expectations of cyclical tests
- Use canonicalizePath for collapsing .. when possible
- Capture trace for later
- Add module for ProjectConfigPath
- Move functions for ProjectConfigPath to its module
- Fetch URI is not prefixed with ./https://etc
- Document normaliseConfigPath
- Add doctests for normaliseConfigPath
- Add doctest of canonicalizeConfigPath
- Show an example of canonical paths
- Use importer and importee in canonicalizeConfigPaths
- Add logging
- Use normLocPath, drop -XMultiWayIf
- Remove seenImports parameter from parseProject
- Follow hlint suggestion: Move brackets to avoid $
- Follow hlint warning: Use mapM
- Follow hlint warning: Use traverse_
- Follow hlint suggestion: Use <$>
- Add failing test skipping across folder
- Remove normaliseConfigPath
- Add hasDuplicatesConfigPath
- Remove lengthConfigPath and nubConfigPath
- Mention cabal-install-solver in the changelog
- Left align project import tree with other content
- Rerun tests to generate left-aligned tree output
- Don't show "constraint from project requires ..."
- Regenerate test outputs without (constraint from project ...)
- Move fail reason printing to project config path module
- Minimize diff of showFR
- Show an "imported by: " list instead of a tree
- Update info logging, avoiding leading spaces
- When logging I found leading spaces were trimmed
- Don't log relative location and path
- Use unicode tree symbol in haddocks
- A duplicate importing tests
- Add Y-forking import test
- A test for detecting when the same config is imported via many different paths
- Fix a typo with ../noncyclical-same-filename-b.config
- Add an intercepting cabal-testsuite/cabal.project
- Use IORef to detect seen imports
- Get rid of seenImports
- Use IORef [FilePath] of uniqueImports
- Add consProjectConfigPath
- Expand the haddocks of newtype ProjectConfigPath
- Clarify, it's the project root directory
- Rename a function to makeRelativeConfigPath
- Fix whitespace
- Update output snippet in changelog
- Put the info logging together
- Split cycles and duplicates detection
- Add fixes and duplicate import to the change log
- Better reporting of duplicate imports
- Report cycles and duplicates using unique file name
- This is after canonicalizeConfigPath, relative to the project directory
- Get rid of fullLocPath, use normLocPath only
- Do reporting using paths relative to the directory of the project
- Issue a warning for Y-shaped duplicate imports
- Add duplicateImportMsg
- Use pretty printing for duplicate import message
- Use pretty printing for all ProjectConfigPath printing
- Drop a parameter from duplicateImportMsg
- Correct haddocks on docProjectConfigPath
- Satisfy fourmolu
- Remove the surplus space in "imported by "
- Log project parsing at the debug level, up from info
- Simplify the changelog snippet
- Use normalized paths for solver messages
- Satisfy fourmolu
- Relative to the directory of the project
- Duplicate imports are reported as warnings
- No need to mention v2-build
- Remove IORef
- Subdue a check for duplicate imports
- TODO: Catch duplicates across different import paths. We know how to do this
- Remove check for duplicate imports
- Improve the canonicalizeConfigPath doctests
- Add haddocks, drop configPath from go
- Make importsBy NonEmpty
- Use testDir in doctests
- Use canonical test directory
- Regenerate expected outputs
- Assume head of the path is the duplicate
- Get rid of duplicateImportMsg
- Remove unused imports in ProjectConfigPath
- Follow hlint suggestion: use fewer imports
- Remove fullConfigPathRoot
- Follow hlint suggestion: redundant bracket
- Use the original "source" variable name
- Put the source next to its contents
- Go with the original "seenImports" variable name
- Avoid -XMultiWayIf
- Not needed since we aren't checking for duplicates right now
- Be consistent in naming sources
- Move project dir alongside related params
- Rename to pathRequiresVersion
- Add back "constraint from"
- Talk only of cycles and not duplicates
- Don't report line number for cyclical import
- Remove 2nd example in changelog
- Remove Y-forked duplicate import test
- Add "imported by" to assertOutputContains
- Cull excess doctests of canonicalizeConfigPath
- Add deep path doctest
- Update haddocks of canonicalizeConfigPath
- remove idempotent speculation (it isn't idempotent)
- use "indirection" to describe "." and ".."
- makes the path relative to the given directory
- Remove seenImports
- Use Explicit ProjectConfigPath
- Missed one "constraint from" in changelog example
- Don't check (verbosity >= verbose) separately
- While the same level of verbosity as info, it is clearer to not check the level separately.
- Might calculate the path but not use it.
- Add AbsoluteDir
- Keep provenance normalised for display
- Remove stale REVIEW comment
- Storing provenance normalized avoids this
- Fix whitespace
- Satisfy HLint warning: Redundant flip
- Gut the repo/hashable packages
- Revert AbsoluteDir to FilePath

This commit makes the library functions in Cabal agnostic of the working
directory. In practice, this means that we distinguish `FilePath`s
from un-interpreted `SymbolicPath`s. The latter may be paths that are
relative to the working directory, and need to be interpreted with
respect to a passed-in argument specifying the working directory,
instead of using the working directory of the current process.
See Note [Symbolic paths] in Distribution.Utils.Path.

In particular, paths in the package description now use the SymbolicPath
abstraction, which allows specifying whether they are allowed to be
absolute, and, if they are relative, what they are relative to.
For example, source files are relative to a source search directory,
data files are relative to the data directory, and doc files are
relative to the package root.

Fixes #9702

As a warning (“Hackage would reject this package”), to prepare users
to GHC language editions.

`cabal init` text for BSD-2-Clause and BSD-3-Clause licence differed
slightly from the one published at SPDX. [1] [2]

This caused some problems to users when dealing with licence-recognition
software. [3]

[1] https://spdx.org/licenses/BSD-2-Clause.html
[2] https://spdx.org/licenses/BSD-3-Clause.html
[3] https://discourse.haskell.org/t/non-standard-license-generated-by-stack-new/9059

https://github.com/haskell/cabal/issues/9641

warning when offline mode skips `source-repository-package`s
i.e.
```
Warning: --offline was specified, skipping sync of repositories:
Warning: https://github.com/haskell/text.git
```

In this PR we make the `--package-db` flag apply only to the default
immutable initial package stack rather than also applying to the store
package database.

There are two special package databases which cabal install knows about
and treats specially.

* The store directory, a global cache of installed packages where cabal
  builds and installs packages into.
* The inplace directory, a local build folder for packages, where cabal
  builds local packages in.

It is very important that cabal registers packages it builds into one of
these two locations as there are many assumptions that packages will end
up here.

With the current design of the `--package-db` flag, you are apparently
allowed to override the store location which should have the effect of
making the last package database in the package stack the "store"
directory. Perhaps this works out in theory but practically this
behaviour was broken and things were always registered into the store
directory that cabal knew about. (The assertion in
`ProjectBuilding.UnpackedPackage` was failing (see added test)).

With `--package-db` not being able to modify the location of the store
directory then the interaction of `--package-db`, `--store-dir` and
`--dist-dir` flags become easy to understand.

* `--package-db` modify the initial package database stack, these
  package database will not be mutated by cabal and provide the initial
  package environment which is used by cabal.
* `--store-dir` modify the location of the store directory
* `--dist-dir` modify the location of the dist directory (and hence
  inplace package database)

Treating the flags in this way also fix an assertion failure when
building packages.

Fixes #9678

Also makes consequent changes.

We use the datatype representation from the globbing in cabal-install,
but preserve a standalone parser for globs present in cabal files, whose
specification is constrained by the cabal specification. The
implementations are merged taking the best parts of each.

We also make sure sdist is robust to accidentally-listed directories,
as the refactor of the globbing modules re-uncovered this issue, and
required a prompt fix for the refactor not to break some things.

Fixes #5349

* Generate changelogs

Co-authored-by: Hécate Moonlight <Kleidukos@users.noreply.github.com>

Hannes Siebenhandl authored 1 year ago and Mikolaj Konarski committed 1 year ago

This reverts commit 3f4c81fd.

This change removes support for building sub-component targets in
cabal-install, since no versions of Cabal support this feature.

The test RunMainBad is also dropped because without the concept of a
file target, RunMainBad is the same test as ScriptBad.

* Ignore invalid Unicode in pkg-config descriptions

Previously, if any of the pkg-config packages on the system had invalid
Unicode in their description fields (like the Intel vpl package has at
the time of writing, 2024-01-11, see #9608), cabal would crash because
it tried to interpret the entire `pkg-config --list-all` output as
Unicode.

This change, as suggested by gbaz in
  https://github.com/haskell/cabal/issues/9608#issuecomment-1886120831


switches to using a lazy ByteString for reading in the output, splitting
on the first space in byte land, and then parsing only the package
_name_ to a String.

For further future-proofing, package names that don't parse as valid
Unicode don't crash Cabal, but are instead ignored.

* Add changelog entry

* cabal-install-solver: Add bounds on 'text'

* No literal ASCII values, use 'ord'

* Address review comments re invalid unicode from pkg-config

* Add test for invalid unicode from pkg-config

* Compatibility with text-1.2.5.0

* Align imports

* Handle different exception type

* Use only POSIX shell syntax

* Add invalid-input handler in pkg-config shim

This is to appease shellcheck

* Actually implement all required stuff in the pkg-config shim

* Less exception dance

* Fix shebang lines

MacOS doesn't have /usr/bin/sh, and /bin/sh is the standard (for a POSIX
shell) anyway

* Don't expect a particular representation of invalid characters

---------

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>