This commit makes Location a separate data type:

  data Location where
    Location
      :: SymbolicPath Pkg (Dir baseDir)
      -> RelativePath baseDir File
      -> Location

instead of being a type synonym for (FilePath, FilePath).

We noted during testing of the Hooks API that it was all too easy to
give an incorrect location for rule outputs, e.g. by omitting an
extension or using an absolute path.
This change allows us to improve the API documentation, as well as
clarifying the types to avoid any ambiguities about what kind of file
path is expected (FilePath vs SymbolicPath).

Add "no command line variant" for `source-repository-package`.

Use bootstrap project in bootstrapping

We need to use the cabal.bootstrap.project file to generate the bootstrap plans, otherwise we try to include test components when bootstrapping, which is not useful (and significantly complicates bootstrapping).

Recommend using latest cabal-install

Render project configs as clean list in provenance message

- Shorten the suggestion to use cabal.release.project
- Move up cabal.release.project for initial build
- Put the --project-file option after as suggested by the command help
- Usage: cabal build [TARGETS] [FLAGS]
- Use the latest markup for note
- $ prefix for command line

- Use real-life example from Cabal project in doctest

Add NoImplicitPrelude to buildTypeScript

This allows us to compile Setup.hs without depending on base.
In particular, this ensures that a package with `build-type: Hooks`
and a custom setup stanza that does not depend on base successfully
compiles.

Tested in PackageTests/SetupHooks/SetupHooksNoBase.

Docs: update link to SetupHooks RFC

The proposal has been accepted, but its final location is in the 'rfc'
subdirectory instead of the 'proposals' subdirectory. This simply
updates the link in the Cabal documentation.

source-repository versus source-repository-package

- Adds pijul as type
- explicit dot is the same as root
- Update doc/cabal-package-description-file.rst
- Grammar, comma required for non-restrictive clause
- Move warning down the section
- Move repository stuff to its own page
- Add author and consumer subsections
- Keep consistent ordering
- Put source-repository before source-repository-package
- Reword intro and add hackage linking
- A field of this type is always optional
- Fix typo
- Put the table into the field types section
- Link to VCS kind, consistent casing
- Introduce the VCS acronym early
- Link to cabal get for this|head
- Update doc/cabal-package-description-file.rst
- Comma after as an example
- Update doc/cabal-package-description-file.rst
- There are two kinds comma
- Split sentences.
- Move to how to section
- Add version control fields
- Rewrite package consumer section
- Bump source packages up a level
- Rename as "how to source packages"
- Rename section, "package source"
- Fix whitespace
- Mention manual download before cabal download
- Use a description list for source-repository fields
- Add a warning about the confusing field names
- Clarify *source code* ``.tar.gz`` archive
- Use Git uppercase
- Source Marker section, marks out
- Change to "inside a single VCS repository"
- Taking a Dependency from a Source Code Repository
- Lead with uppercase first letter for Darcs, Git
- Fix whitespace
- Use lowercase for titles
- Change the guide title to "How to get package *source code*".
- Hackage is for published, exact versus range of versions
- Mention cabal get
- Lead with uppercase for Cabal and Hackage
- Move VCS fields up in the tree
- Mention *source code* in all the section titles
- Explain how linking helps contributors and maintainers
- Add an example of conversion
- Add a dependency vendoring section
- Show cloning with cabal build --dry-run
- Keep VCS fields small
- Add diagrams
- Warn about hash in clone folder name
- Use code style for .cabal
- Use lower caps in title to match other sections
- Add missing _ for external link reference
- Move package authoring section to last
- Use subsections for vendoring
- Add a section about publishing
- Fix up anchors and references
- Typo, "extracts it to a directory"
- It is a "``cabal get`` unpacking step"
- Use a comma in "Fork, don't vendor"
- Add a tag to the src-repo-pkg example
- The warning about commits is only for Git repositories
- Move note to setting up section
- Fix whitespace
- Missing source-repository ead in the diff
- Use with/without a "-package" suffix ... belongs
- Add a reference to cabal get
- How to locate and get
- Add back the ref to the package consumer section
- Replace arrowheads with ASCII
- Replace ticked checkboxes with ASCII
- Warn about project and the set of pkgs separately
- Multiple dependency packages not multiple dependencies
- Shorter explanation of vendoring
- Lower caps for bold terms
- Add references to VCS fields
- A marker that points to
- Use the shorter "shepherd"
- Use grab (not obtain) before obtaining
- Clarify terms in source code note
- Hackage is only for published package dependencies
- Add a link to hackage upload
- Add a footnote about packages of a cabal.project
- Revert section title to "Specifying the local packages"
- Change shepherd to "deal with"
- Put source after package, ordering how to guides
- Comma after as

Co-Authored-By: Artem Pelenitsyn <a.pelenitsyn@gmail.com>
Co-Authored-By: brandon s allbery kf8nh <allbery.b@gmail.com>

Haddock: use buildSettingKeepTempFiles

This commit initialises the Haddock flag haddockKeepTempFiles with the
value of buildSettingKeepTempFiles.

This addresses an 8 year old TODO in the code, from Duncan Coutts.

Downgrade NoLibraryFound from an error to a warning

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

Touch up release notes for cabal-install 3.12.0.0 pre-release

How to use Cabal in Windows

Hackage as a proper noun, capitalized in docs

update `base` bounds for desupported ghc 8.2

More consistently pass --package-db flag to tests

Previously `--package-db` was only passed to test which used the `v2-`
prefix.

Now we pass `--package-db` to things which use the `v2-` prefix, not
things which use the `v1-` prefix and by default assume that unprefixed
commands are v2 commands.

Filter Setup flags: filter working dir on < 3.13

The --working-dir flag is only available for Cabal >= 3.13.
This commit fixes an incorrect conditional: we only filtered out this
flag for Cabal < 3.11, instead of < 3.13.

Test: PackageTests/WorkingDir

Fixes #9940

Bump to hlint-3.8

Rename projects to have `.project` extension

Correctly provision build tools in all situations

This patch ensures that we correctly provision executables declared
in the build-tool-depends fields in all circumstances:

  - whether the build tool is external (from another package) or
    internal (declared in the current package)
  - whether the build tool is used at compile time (e.g. in a pre-build
    rule or in a Template Haskell splice) or at run time (e.g. when
    running a test-suite, benchmark or executable).

Note that correctly provisioning a build tool requires two pieces of
information:

  - making it available in PATH,
  - ensuring it has the correct environment variables overrides;
    in particular, the build tool needs to be able to find its own
    data directory.

The test case BuildToolPaths checks all of these situations are handled
correctly.

This commit ensures the test-suite driver also provides the Cabal-hooks
package, on top of Cabal and Cabal-syntax.

Define a user-visible change

Update PR template