Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Cabal plugin infrastructure #7825

Open
Kleidukos opened this issue Nov 18, 2021 · 10 comments
Open

[RFC] Cabal plugin infrastructure #7825

Kleidukos opened this issue Nov 18, 2021 · 10 comments
Labels
type: RFC Requests for Comment

Comments

@Kleidukos
Copy link
Member

Kleidukos commented Nov 18, 2021

This is a WIP. Fendor & I will edit this description to refine the features & requirements.

Inspirations

  • git
  • cargo

Reasoning

To avoid bloat in cabal-install CLI and offer a more ergonomic way to use plugins, we must offer first-class support for cabal CLI plugins.

More importantly, it allows us to provide features in "beta" or "experimental" status to our users before integrating them into the CLI codebase when they are more mature.
This is a low-tech solution but tech is not the only aspect being considered here.

What we need

  • Plugin infrastructure for cabal CLI

    • cabal instal --plugin
      • It is installed in ~/.cabal/bin XOR ~/.cabal/plugins/bin
      • When people type cabal foo, if foo is not a valid subcommand, we lookup cabal-foo in the bin directory.
    • Provide a cabal-metadata package as companion tooling for plugin authors
      • Provide structure representation of the plan.json & build-info.json
    • Handle incompatibilities between Cabal versions. Need more thought.
      • JSON incompatibilities
      • Binary incompatibilities
  • Cabal version compatibility

    • One plugin version per project?
    • One plugin version per installed ghc.
      • Call ghcup directly to install cabal plugins. Symlink logic is reused, the same as HLS
  • Cabal command-line arguments passing

    • This amounts to calling another binary with the parameters passed. Do we want to setup some stuff on the cabal-install side (like environment variables) before calling the binary (cabal-foo in ~/.cabal/bin)?

cc @fendor

@jneira
Copy link
Member

jneira commented Nov 18, 2021

Having that would be really great, thanks for the proposal

Related: #2349, #2395

@gbaz
Copy link
Collaborator

gbaz commented Nov 18, 2021

I have a fair amount of trepidation about this, and my main comment would be that we should follow the model of git and cargo, which seems to be proposal #2349 and keep this as simple as possible. I propose that we do not need to have a --plugin flag for cabal install. It just installs plugins like any other binaries. It just looks up executables by name to execute subcommands, and further, perhaps, lists them under cabal --help. I also suggest we do nothing directly to enforce version compat, and we do nothing to worry about cli or env argument passing. I.e. this is just sugar for invoking a subcommand.

Anything else, while feeling "clever" at first, will in my estimation lead to more confusing and undocumented behavior in the long run.

@Kleidukos
Copy link
Member Author

@gbaz thanks for restricting the scope :)

@Ericson2314
Copy link
Collaborator

Ericson2314 commented Nov 18, 2021

I don't think cabal-foo vs cabal foo is a very high priority thing to worry about. I have used Cargo plugins and git plugins and don't really see the point of that feature over there either.

However, trying to break out some libraries from Cabal and cabal-install with just parsers and ASTs is always a good idea, and one I am perennially excited about :). (We should do the same thing with GHC too, so ghc depends on ghc-lib-parser or so!)

@Kleidukos
Copy link
Member Author

Kleidukos commented Nov 18, 2021

I don't think cabal-foo vs cabal foo is a very high priority thing to worry about. I have used Cargo plugins and git plugins and don't really see the point of that feature over there either.

@Ericson2314 They give better ergonomy and first-class support that we can improve later on. We can also organise a "beta" workflow of new subcommands if they can live in separate binaries during their "experimental" life cycle, before being integrated in the codebase of the CLI.

Thank you for your support regarding cabal-metadata. :)

@jneira
Copy link
Member

jneira commented Nov 19, 2021

They give better ergonomy and first-class support that we can improve later on. We can also organise a "beta" workflow of new subcommands if they can live in separate binaries during their "experimental" life cycle, before being integrated in the codebase of the CLI.

That is a key argument, we could, for example, bring here cabal-plan and have cabal plan almost for free

@Kleidukos
Copy link
Member Author

@jneira The idea was to implement the featureset described here as a plugin: #7500 (comment)

@Kleidukos Kleidukos changed the title WIP: Cabal plugin infrastructure [RFC] Cabal plugin infrastructure Feb 10, 2022
@Kleidukos Kleidukos added the type: RFC Requests for Comment label Feb 10, 2022
@yvan-sraka
Copy link
Collaborator

After reading through the discussions here (and discussing it while ZuriHac with @Kleidukos), I propose to stick to a simple, straightforward approach for a cabal-install CLI plugin system, inspired by how git and cargo handle commands:

  1. Treat each plugin as a standalone executable named cabal-$COMMAND in the PATH. It should be callable as cabal $COMMAND ;
  2. Pass any additional CLI arguments directly to this command. This allows plugins to range from a simple shell script to more complex applications ;
  3. Rather than, e.g., passing data in specific formats like JSON or constraining the user to link their program against the Cabal library, we provide necessary information (like GHC version or project root directory) as ENV variables. This allows plugins to rely on cabal-install CLI or Cabal library as they wish, or not at all. cargo follows a similar approach: https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-3rd-party-subcommands

I've taken a brief look at the Cabal codebase, and it seems feasible to implement this approach just by slightly modifying this function:

commandsRun
:: CommandUI a
-> [Command action]
-> [String]
-> CommandParse (a, CommandParse action)
commandsRun globalCommand commands args =
case commandParseArgs globalCommand True args of
CommandHelp help -> CommandHelp help
CommandList opts -> CommandList (opts ++ commandNames)
CommandErrors errs -> CommandErrors errs
CommandReadyToGo (mkflags, args') -> case args' of
("help" : cmdArgs) -> handleHelpCommand cmdArgs
(name : cmdArgs) -> case lookupCommand name of
[Command _ _ action _] ->
CommandReadyToGo (flags, action cmdArgs)
_ -> CommandReadyToGo (flags, badCommand name)
[] -> CommandReadyToGo (flags, noCommand)
where
flags = mkflags (commandDefaultFlags globalCommand)
where
lookupCommand cname =
[ cmd | cmd@(Command cname' _ _ _) <- commands', cname' == cname
]
noCommand = CommandErrors ["no command given (try --help)\n"]
-- Print suggested command if edit distance is < 5
badCommand :: String -> CommandParse a
badCommand cname =
case eDists of
[] -> CommandErrors [unErr]
(s : _) ->
CommandErrors
[ unErr
, "Maybe you meant `" ++ s ++ "`?\n"
]
where
eDists =
map fst . List.sortBy (comparing snd) $
[ (cname', dist)
| (Command cname' _ _ _) <- commands'
, let dist = editDistance cname' cname
, dist < 5
]
unErr = "unrecognised command: " ++ cname ++ " (try --help)"
commands' = commands ++ [commandAddAction helpCommandUI undefined]
commandNames = [name | (Command name _ _ NormalCommand) <- commands']
-- A bit of a hack: support "prog help" as a synonym of "prog --help"
-- furthermore, support "prog help command" as "prog command --help"
handleHelpCommand cmdArgs =
case commandParseArgs helpCommandUI True cmdArgs of
CommandHelp help -> CommandHelp help
CommandList list -> CommandList (list ++ commandNames)
CommandErrors _ -> CommandHelp globalHelp
CommandReadyToGo (_, []) -> CommandHelp globalHelp
CommandReadyToGo (_, (name : cmdArgs')) ->
case lookupCommand name of
[Command _ _ action _] ->
case action ("--help" : cmdArgs') of
CommandHelp help -> CommandHelp help
CommandList _ -> CommandList []
_ -> CommandHelp globalHelp
_ -> badCommand name
where
globalHelp = commandHelp globalCommand

This method keeps the system simple and functional, gives users more control over plugin creation and installation, and allows for a “beta” workflow for new commands before they're integrated into the CLI codebase. WDYT @fendor?

@fendor
Copy link
Collaborator

fendor commented Jun 19, 2023

Hi!

After discussing the proposed solution with @Kleidukos, this looks like a good way forward! I don't have much to add for now, looking forward to the PR!

yvan-sraka added a commit to yvan-sraka/cabal that referenced this issue Jun 21, 2023
yvan-sraka added a commit to yvan-sraka/cabal that referenced this issue Jun 23, 2023
yvan-sraka added a commit to yvan-sraka/cabal that referenced this issue Jul 10, 2023
yvan-sraka added a commit to yvan-sraka/cabal that referenced this issue Jul 11, 2023
yvan-sraka added a commit to yvan-sraka/cabal that referenced this issue Jul 24, 2023
yvan-sraka added a commit to yvan-sraka/cabal that referenced this issue Sep 7, 2023
yvan-sraka added a commit to yvan-sraka/cabal that referenced this issue Oct 28, 2023
@Kleidukos
Copy link
Member Author

Kleidukos commented Oct 31, 2023

I have a question: should we encourage the usage of extra field (starting with x-) in cabal.project? I'm writing a cabal plugin that would read from the codebase, and obviously the maintainers of a project may want to exclude some paths, and specifying file patterns.

@gbaz This question is for you: Was there ever a plan to support arbitrary stanzas that operate the same as source-repository-package (that is, with subfields)? If they started with x- (like in the .cabal format), cabal-install could treat them as opaque and the tools would bring their own parser for the file.

I'm especially looking at

sourceRepositoryPackageGrammar
:: ( FieldGrammar c g
, Applicative (g SourceRepoList)
, c (Identity RepoType)
, c (List NoCommaFSep FilePathNT String)
, c (NonEmpty' NoCommaFSep Token String)
)
=> g SourceRepoList SourceRepoList
sourceRepositoryPackageGrammar =
SourceRepositoryPackage
<$> uniqueField "type" srpTypeLens
<*> uniqueFieldAla "location" Token srpLocationLens
<*> optionalFieldAla "tag" Token srpTagLens
<*> optionalFieldAla "branch" Token srpBranchLens
<*> monoidalFieldAla "subdir" (alaList' NoCommaFSep FilePathNT) srpSubdirLens -- note: NoCommaFSep is somewhat important for roundtrip, as "." is there...
<*> fmap (maybe [] toList) pcc
where
pcc = optionalFieldAla "post-checkout-command" (alaNonEmpty' NoCommaFSep Token) srpCommandLensNE
and I wonder if the plugins couldn't define their own (since most of the stuff is defined in Cabal-syntax).

However the parser itself is defined in cabal-install, so that would mean taking it out? I'm not super confident that it is a painless process.

Mikolaj pushed a commit to yvan-sraka/cabal that referenced this issue Nov 2, 2023
erikd pushed a commit to erikd/cabal that referenced this issue Nov 6, 2023
erikd pushed a commit to erikd/cabal that referenced this issue Nov 6, 2023
erikd pushed a commit to erikd/cabal that referenced this issue Nov 7, 2023
alt-romes pushed a commit to alt-romes/cabal that referenced this issue Nov 28, 2023
alt-romes pushed a commit to alt-romes/cabal that referenced this issue Nov 30, 2023
mergify bot added a commit that referenced this issue Dec 2, 2023
…ange only. (#9386)

* add more breadcrumbs for how to use remote packages.

* Hackage should be capitalized

* Update doc/cabal-project.rst

reword.

* Update doc/cabal-project.rst

reword.

* Update doc/cabal-project.rst

clearer.

* Update doc/cabal-project.rst

clearer!

* Update doc/cabal-project.rst

good mechanical description.

* wrap.

* Update doc/cabal-project.rst

add missing double ticks.

* clarify english, and follow a linguistic pattern better.

* Update doc/cabal-project.rst

* doc: render math with HTML to make it selectable (fix #8453) (#9361)

* doc: render math with HTML to make it selectable (fix #8453)

* Update doc/conf.py

Co-authored-by: Bryan Richter <bryan@haskell.foundation>

---------

Co-authored-by: Bryan Richter <bryan@haskell.foundation>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

* Avoid double space in "Executing install plan ..."

* Add a change log entry for double space avoidance

* Ignore CmmSourcesExe Demo

Ignore because it warns about missing MachDeps.h

* [cabal-7825] Implement external command system

Fix #2349 and #7825

* Bump to latest dependencies for GHC 9.8.1

* cabal.project: clean out obsolete `allow-newer`s

* update GH validate workflow to ghc 9.2.8, 9.4.7, 9.6.3

* Revert #3639 (Don't pass -package-db and -package flags to --abi-hash) (#9384)

* Revert #3639 (Don't pass -package-db and -package flags to --abi-hash)

With ghc>=9.6 `ghc --abi-hash` initialises the plugins so it will fail
if a cabal file specifies `ghc-options: -fplugin=Foo`.

Closes: #9375

* Also revert in GHC.hs

---------

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

* Use the newer haskell-actions organisation

* Restructure Cabal documentation top-level parts

The goal is for users to easier find pages for typical problems through search engines and page navigation.
- The top-level layout is based on the popular documentation structure by https://documentation.divio.com/ to give a
   clear structure to users and future documentation contributors:
  * Guides: Present a solution to a single, atomic, typical user problem.
  * Reference: Describe user API (CLI fields, syntax etc) with technical rigour and completeness.
  * Explanation: Discuss background information, scope, design decisions etc.
- Move existing documentation roughly into these categories with minimal editing as the basis for further editing.
- Rename guide titles to mention how-to for improving SEO.
- Rename some files to improve SEO since that name becomes part of the URL (often called slug).
  Important page keywords should appear in the slug as well to make pages rank higher in search engines.

* Rename master_doc to root_doc (changed in version 4.0 of Sphynx)

* Add instance Ord for Field, FieldLine, SectionArg and Name

* Do not run CI for documentation changes

The github workflows are not run if the
changes are completely contained within
the doc/ subdirectory. The only exception
is the users-guide.yml github action.

* Move Backpack section to user guides

* Remove TBW virtual modules section

* Add reinstall test to LinkerOptions/NonignoredConfigs

* Record install options

* Reject index-states after last known index-state (#8944)

Co-authored-by: Javier Sagredo <jasataco@gmail.com>
Co-authored-by: Andrea Bedini <andrea.bedini@tweag.io>
Co-authored-by: Andrea Bedini <andrea@andreabedini.com>

* Note how to do "not equal" with constraints

* Use comma with then

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

* Use narrow rather than upset

* Say something about hackage deprecations

* Fix AutogenModulesToggling test

By converting this to a setupTest we use the in-tree Cabal library
rather than relying on a proxy of the GHC version to provide the right
Cabal library version.

Supersedes #9398

* Require version 3,11 of Cabal to support --semaphore flag

Fixes #9197

* Add dependencies used by `PackageTests` to exe:cabal-tests

The runner allows the tests to use extra dependencies and the custom Prelude
from 'cabal-testsuite'.
However, if the tests use a dependency, say 'directory', and there are two
packages with the same unit id available in the store, the test fails since
it doesn't know which one to pick.
By including an extra dependency to directory, we force the test runner to
use a specific version directory, fixing the test failure.

* Use Paths_cabal_install for cabal-install version number (#9421)

* Use PackageInfo for cabal-install version number

* Use Paths_cabal_install instead

* Adjust documentation

---------

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

* Document --profiling-detail in setup-commands.

Fixes #9182

* Add test requirement to PR template

Adding test becomes a checkmark instead of “bonus points”.

* A 'cabal path' command. (#8879)

* Add a 'cabal path' command.

* Formatting fix.

* Another formatting fix.

* Categorise "cabal path" as global command.

* Allow individual paths to be printed.

* Less duplication.

* Add config-file to "cabal path".

* Use sum type instead of strings.

* cabal path: support --installdir.

* Add documentation.

* Better text.

* Formatting.

* Add some tests.

* Improve tests.

* Add changelog entry.

* Mention "cabal path" in directory documentation.

---------

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

* Reimplement `cabal check` (#8427)

* Fix Semigroup target instance

When two target names are the same, `mappend`ing them should not
error but just pick the first name.

* Add `desugarBuildToolSimple`

* Reimplement cabal check

* Reorder test output

* Fix autogen modules tests .cabal files

* Add a number of tests

* Add test for #7423

i.e. Do not warn on -O2 if under off-by-default package configuration
flag conditional.

* Add a regression for:

    * Add another -WErrr test
        This is to make sure we do *not* report it if it is under
        a user, off-by-default flag.
    * Add test for non manual user flags.
    * Add “absolute path in extra-lib-dirs” test
    * Add if/else test
    * Add “dircheck on abspath” check
    * Add Package version internal test
    * Add PackageVersionsStraddle test

* Add changelog for #8427

* Integrate various reviews

* Integrate Artem’s review

(review) Clarify `combineNames` documentation

By explaining the way it operates (working if the two names are equal
or one is empty) and renaming the function from `combineName` to
`combineNames`.

(review) Use guards instead of if/then/else

(review) Match inside argument list

(review) Replace “white” with “allow”

(review) Fix typo in comment

(review) Fix typo in Check module documentation

(review) Harmonise indentation for `data` decls

First field goes in a new line than the data constructor, so we
have more space.

(review) Rename `Prim` module to `Types`

(review) Add checkPackageFilesGPD

`checkPackageFiles` — which works on PD — was used to perform IO. We
introduce a function that does the same thing but works on GPD (which
is more principled).

`checkPackageFiles` cannot just be removed, since it is part of the
interface of Distribution.PackageDescription.Check. Deprecation can
be planned once “new check” is up and running.

* Integrate Andreas’ review

(review) Add named section to missing upper bound check

“miss upper bound” checks will now list target type and name (“On
executable 'myexe', these packages miss upper bounds”) for easier
fixing by the user.

(review) remove `cabal gen-bounds` suggestion

Reasonable as `cabal gen-bounds` is stricter than `cabal check`, see
#8427 (comment)
Once `gen-bounds` behaves in line with `check` we can readd the
suggestion.

(review) Do not warn on shared bounds

When a target which depends on an internal library shares some
dependencies with the latter, do not warn on upper bounds.

An example is clearer

    library
     build-depends: text < 5
    ⁝
     build-depends: myPackage,        ← no warning, internal
                    text,             ← no warning, shared bound
                    monadacme         ← warning!

* Integrate Artem’s review /II

(review) Split Check.hs

Check.hs has been split in multiple file, each une sub 1000 lines:

Check              857 lines
Check.Common       147 lines
Check.Conditional  204 lines
Check.Monad        352 lines
Check.Paths        387 lines
Check.Target       765 lines
Check.Warning      865 lines

Migration guide:
- Check              GPD/PD checks plus work-tree checks.
- Check.Common       common types and functions that are
                     *not* part of monadic checking setup.
- Check.Conditional  checks on CondTree and related matter
                     (variables, duplicate modules).
- Check.Monad        Backbone of the checks, monadic inter-
                     face and related functions.
- Check.Paths        Checks on files, directories, globs.
- Check.Target       Checks on realised targets (libraries,
                     executables, benchmarks, testsuites).
- Check.Warning      Datatypes and strings for warnings
                     and severities.

(review) remove useless section header

(review) Fix typo

(review) Add warnings documentation (list)

For each warning, we document constructor/brief description
in the manual.  This might not be much useful as not but it
will come handy when introducing `--ignore=WARN` and similar
flags.

* (review Andreas) Clarify CheckExplanation comment

Whoever modifies `CheckExplanation` data constructors needs to be
aware that the documentation in  doc/cabal-commands.rst  has to be
updated too.

* Move internal Check modules to `other-modules`

No need to expose Distribution.PackageDescription.Check.*
to the world. API for checking, for cabal-install and other
tools, should be in Distribution.PackageDescription.Check.

* Make fourmolu happy

Cabal codebase has now a formatter/style standard (see #8950).

“Ravioli ravioli, give me the formuoli”

* Do not check for OptO in scripts

See #8963 for reason and clarification requests.

* Remove useless PackageId parameter

It is now in the Reader part of CheckM monad.

* Do not check PVP on internal targets

Internal: testsuite, benchmark.
See #8361.

* Make hlint happy

* Fix #9122

When checking internal version ranges, we need to make sure we
are not mistaking a libraries with the same name but from different
packages. See #9132.

* Fix grammar

neither…nor, completing what done in #9162

* Integrate Brandon’s review: grammar

* Remove unnecessary `-fvia-C` check

Brandon’s review/II.

---------

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

* ci: Enable windows tests for 9.6.3

There were two failing tests:

1. CCompilerOverride, was attempting to use gcc.exe rather than
   clang.exe without also overriding the C options which led to
   incorrect options being passed to gcc.exe. The fix is to override to
   clang.exe on ghc-9.4 or newer.
2. ForeignLibs exposes a bug in GHC
   (https://gitlab.haskell.org/ghc/ghc/-/issues/24185) and hence is
   skipped for GHCs newer than 9.4 where it was first introduced.

Towards fixing #8451, we just need to fix the shared library issue now.

* testsuite: Be explicit about runtime test dependencies

Issue #8356 reports occasional errors from running the testsuite about
multiple package versions available. This stems from the invokation of
`runghc` not being explicit about all dependencies of the testsuite.

The solution is provide a component in the cabal file which is explicit
about which packages the tests can depend on. This component has a
build-depends section which lists all the dependencies that the tests
require.

It would be better if this component was a library component but we
can't do this with a Custom setup because of limitations to do with
per-component builds.

Then we also enable `-hide-all-packages`, so the dependency will not be
available if it is not explicitly listed as a dependency.

You could also imagine a future where the Setup.hs script found the test
files and compiled a single executable which would run all the tests,
rather than invoking runghc on each one individually.

Fixes #8356

* hurd: Enable using $ORIGIN in RPATH

GNU/Hurd fully supports RPATH and the $ORIGIN development, and we indeed
want to use it for relocatable installations shipped in Debian GNU/Hurd.

* Fix the platform string for GNU/Hurd

Since version 9.4.7-1, ghc fails to build on the GNU/Hurd port of Debian,
see

https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=hurd-i386&ver=9.4.7-1&stamp=1697717885&raw=0

Error, rule finished running but did not produce file:
  _build/stage0/lib/i386-gnu-ghc-9.4.6/ghc-boot-th-9.4.7/libHSghc-boot-th-9.4.7.a

and indeed, what did get produce was rather
_build/stage0/lib/i386-hurd-ghc-9.4.6/ghc-boot-th-9.4.7/libHSghc-boot-th-9.4.7.a
(i386-hurd instead of i386-gnu).

This is due to confusion between hurd and gnu in various places.  Apparently
previous versions of ghc were using gnu for the GNU/Hurd port, and thus
putting libraries etc. in i386-gnu. So we have to follow the existing
practice.

* Fix configuation of ldProgram

Standard GNU `ld` ues `--relocatable` while `ld.gold` uses a `-relocatable`
flag (with a single `-`). Code will now detect both versions.

* Chain configuration of ldProgram

`ldProgram` gets configured in two places, a seemingly default and
a GHC specific version. The later needs to be updated so that it
first calls the default configuration and then the new GHC version.

* Use linker capability detection to improve linker use

The function `comperSupportsGhciLibs` has been renamed to
`linkerSupportsGhciLibs` because its about the linker not the compiler.

The function `comperSupportsGhciLibs` was using the compiler version
as a proxy for whether the linker supports relocatable objects. Now
support for relocatable objects is detected by running the linker.

* add `merge+no rebase`

and a few typos while reviewing

* Add support for 64-bit SPARC as a separate architecture

Previously, sparc64 was defined as an alias for the 32-bit SPARC
architecture which was true while SPARC mainland was mostly 32
bits. More recently, 64-bit SPARC has become a port of its own,
so it needs to be treated as a separate architecture.

* Remove debug-conflict-sets flag from solver package

Fixes #8937.

The debug-conflict-sets build flag probably hasn't been used for a long time,
and it isn't currently tested. This commit removes the flag, converts the
ConflictSet type back to a newtype, and removes an unnecessary instance.

* Finish improvements to the CI configuration for documentation changes (#9460)

* Add bootstrap postjob to CI config

Add a new job to the bootstrap.yml GitHub action config.
This job succeeds if, and only if, all the other bootstrap
jobs succeed.

* Do not run bootstrap CI jobs for documentation changes

The approach was already introduced in #9355 for the validate jobs.
This commit introduces the same change also for the bootstrap jobs.

* Also ignore CONTRIBUTING.md and README.md in CI

We do not run the entire CI suite for documentation changes.
Previously, only changes which were restricted to the 'docs/'
subdirectory were considered to be documentation changes.
With this commit we also recognize changes to README.md and
CONTRIBUTING.md as documentation changes.

* Document improved CI for documentation in CONTRIBUTING.md

The CONTRIBUTING.md file now mentions that documentation changes
do not waste expensive CI resources.

* Recognize all README.md in subdirs as documentation

Expensive CI jobs should not run on changes which affect only
README.md files.

* formatting: Add style-commit makefile target

This target allows you to format a range of commits, for example:

```
make style-commit COMMIT=HEAD~1
> Last commit is formatted
make style-commit COMMIT=abcde
> Commits between HEAD and abcde are formatted
```

* Fix assertion failure when combining build-tool-depends and --enable-documentation

The `setDocumentation` function was modifying the elaborated package
after the hash was computed. This led to the assertion failing as the
computed hash was different to what was computed in the initial install
plan.

Therefore in order to fix this we either needed to:

1. Set elabBuildHaddocks = False at the point where the hash is
   initially computed.
2. Verify that elabBuildHaddocks = True will not lead to unexpected
   results.

The latter has been implemented.

The elabBuildHaddocks option is only consulted in
`hasValidHaddockTargets`, at which point documentation building the
executable component is disabled because elabHaddockExecutables is
False.

In the added test we ensure this by checking that we didn't build
documentation for the executable which is built because of
build-tool-depends.

Fixes #6006 #8313

* testsuite: Improve error message in findDependencyInStore

* Only move code to Simple/GHC/Build*

* CPP mingw32_HOST_OS for more imports

* cabal-install-solver: fix pkgconf 1.9 --modversion regression

Check that the numbers of *versions* output is equal to the number of pkgconf's

fixes #8923

The pkgconf behavior was reverted upstream in 2.0

(this should cover the case too of checking that equal pkgList lines are output also)

* External commands: Add tests for #9402 #9403 #9404

This adds 4 tests which test the new external commands feature:

* ExternalCommand - Tests the expected usage of external command invoked
  via cabal-install
* ExternalCommandSetup - Tests that the ./Setup interface does not
  support external commands (#9403)
* ExternalCommandEnv - Tests that environment variables are set and
  preserved appropiately  (#9402)
* ExternalCommandHelp - Test that `cabal help <cmd>` is interpreted appropiately (#9404)

* Finish off the external commands feature

* Remove 'CommandDelegate' in favour of abstracting the fallback in
  'commandsRun', there is a new variant 'commdandRunWithFallback' which
  takes a continuation
  - This restores the modularity between the `Cabal` library and
    `cabal-install` as now `Cabal` doesn't need to know anything about
    the external command interface.
  - Fixes #9403
* Set the $CABAL environment variable to the current executable path
  - This allows external commands to be implemented by calling $CABAL,
    which is strongly preferred to linking against the Cabal library as
    there is no easy way to guantee your tool and `cabal-install` link
    against the same `Cabal` library.
  - Fixes #9402
* Pass the name of the argument
  - This allows external commands to be implemented as symlinks to an
    executable, and multiple commands can be interpreted by the same
    executable.
  - Fixes #9405
* `cabal help <cmd>` is interpreted as `cabal-<cmd> --help` for external
  commands.
  - This allows the `help` command to also work for external
  commands and hence they are better integrated into cabal-install.
  - Fixes #9404

The tests are updated to test all these additions.

These features bring the external command interface up to par with the
cargo external command interface.

* Use Base16 hash for script path.

Issue #9334 shows that `%` characters on Windows result in invalid
paths, also `/` characters on Linux create invalid paths.

This changes from using base64 to using base16 with the same length
we use for unit-ids.

* Migrate to haskell-actions/setup

As of 2023-09-09, haskell/action/setup is no longer maintained.

The comment

  # latest is mandatory for cabal-testsuite, see #8133

is removed; as the validate job was already fixing a version of cabal-install.

* testsuite: Introduce Cabal-tests library for common testsuite functions

I noticed that Distribution.Utils.TempTestDir was only used in the
testsuite but defined in the Cabal library. Rather than expose this in
the public interface of the `Cabal` library, it is cleaner to refactor
it into a separate library (`Cabal-tests`) which can be used by any
testsuite component.

Also, in future it gives a clearer place to put utility functions which
need to be shared across the testsuite but not exposed in Cabal.
Cabal-tests can also freely add dependencies (such as exceptions) which
we might want to avoid adding to the Cabal library.

Fixes #9453

* GHC 9.8 compat: pacify -Wx-partial

* GHC 9.8 compat: update hashes of data structures as computed by Structured

It seems, GHC 9.8 changed something in the code generation for data types.
Structured class is supposed to catch such cases.

* GHC 9.8 compat: bump base, update Unknown GHC

And bump Cabal's "supported version" of GHC

* CI: GHC 9.8

* merge master

* Hackage should be capitalized

---------

Co-authored-by: Artem Pelenitsyn <a.pelenitsyn@gmail.com>
Co-authored-by: Bryan Richter <bryan@haskell.foundation>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Co-authored-by: Phil de Joux <philderbeast@gmail.com>
Co-authored-by: Yvan Sraka <yvan@sraka.xyz>
Co-authored-by: Andreas Abel <andreas.abel@ifi.lmu.de>
Co-authored-by: Jens Petersen <petersen@redhat.com>
Co-authored-by: Andrea Bedini <andrea.bedini@tweag.io>
Co-authored-by: Hamish Mackenzie <Hamish.K.Mackenzie@gmail.com>
Co-authored-by: Malte Neuss <malteneuss@users.noreply.github.com>
Co-authored-by: Bodigrim <andrew.lelechenko@gmail.com>
Co-authored-by: David Binder <david.binder@uni-tuebingen.de>
Co-authored-by: David Binder <binderd@informatik.uni-tuebingen.de>
Co-authored-by: Javier Sagredo <jasataco@gmail.com>
Co-authored-by: Andrea Bedini <andrea@andreabedini.com>
Co-authored-by: Matthew Pickering <matthewtpickering@gmail.com>
Co-authored-by: Fendor <power.walross@gmail.com>
Co-authored-by: Hécate Moonlight <Kleidukos@users.noreply.github.com>
Co-authored-by: Andreas Klebinger <klebinger.andreas@gmx.at>
Co-authored-by: Francesco Ariis <fa-ml@ariis.it>
Co-authored-by: Troels Henriksen <athas@sigkill.dk>
Co-authored-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Co-authored-by: Erik de Castro Lopo <erikd@mega-nerd.com>
Co-authored-by: brandon s allbery kf8nh <allbery.b@gmail.com>
Co-authored-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Co-authored-by: Kristen Kozak <grayjay@wordroute.com>
Co-authored-by: Javier Sagredo <javier.sagredo@iohk.io>
alt-romes pushed a commit to alt-romes/cabal that referenced this issue Dec 4, 2023
alt-romes pushed a commit to alt-romes/cabal that referenced this issue Dec 4, 2023
…ange only. (haskell#9386)

* add more breadcrumbs for how to use remote packages.

* Hackage should be capitalized

* Update doc/cabal-project.rst

reword.

* Update doc/cabal-project.rst

reword.

* Update doc/cabal-project.rst

clearer.

* Update doc/cabal-project.rst

clearer!

* Update doc/cabal-project.rst

good mechanical description.

* wrap.

* Update doc/cabal-project.rst

add missing double ticks.

* clarify english, and follow a linguistic pattern better.

* Update doc/cabal-project.rst

* doc: render math with HTML to make it selectable (fix haskell#8453) (haskell#9361)

* doc: render math with HTML to make it selectable (fix haskell#8453)

* Update doc/conf.py

Co-authored-by: Bryan Richter <bryan@haskell.foundation>

---------

Co-authored-by: Bryan Richter <bryan@haskell.foundation>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

* Avoid double space in "Executing install plan ..."

* Add a change log entry for double space avoidance

* Ignore CmmSourcesExe Demo

Ignore because it warns about missing MachDeps.h

* [cabal-7825] Implement external command system

Fix haskell#2349 and haskell#7825

* Bump to latest dependencies for GHC 9.8.1

* cabal.project: clean out obsolete `allow-newer`s

* update GH validate workflow to ghc 9.2.8, 9.4.7, 9.6.3

* Revert haskell#3639 (Don't pass -package-db and -package flags to --abi-hash) (haskell#9384)

* Revert haskell#3639 (Don't pass -package-db and -package flags to --abi-hash)

With ghc>=9.6 `ghc --abi-hash` initialises the plugins so it will fail
if a cabal file specifies `ghc-options: -fplugin=Foo`.

Closes: haskell#9375

* Also revert in GHC.hs

---------

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

* Use the newer haskell-actions organisation

* Restructure Cabal documentation top-level parts

The goal is for users to easier find pages for typical problems through search engines and page navigation.
- The top-level layout is based on the popular documentation structure by https://documentation.divio.com/ to give a
   clear structure to users and future documentation contributors:
  * Guides: Present a solution to a single, atomic, typical user problem.
  * Reference: Describe user API (CLI fields, syntax etc) with technical rigour and completeness.
  * Explanation: Discuss background information, scope, design decisions etc.
- Move existing documentation roughly into these categories with minimal editing as the basis for further editing.
- Rename guide titles to mention how-to for improving SEO.
- Rename some files to improve SEO since that name becomes part of the URL (often called slug).
  Important page keywords should appear in the slug as well to make pages rank higher in search engines.

* Rename master_doc to root_doc (changed in version 4.0 of Sphynx)

* Add instance Ord for Field, FieldLine, SectionArg and Name

* Do not run CI for documentation changes

The github workflows are not run if the
changes are completely contained within
the doc/ subdirectory. The only exception
is the users-guide.yml github action.

* Move Backpack section to user guides

* Remove TBW virtual modules section

* Add reinstall test to LinkerOptions/NonignoredConfigs

* Record install options

* Reject index-states after last known index-state (haskell#8944)

Co-authored-by: Javier Sagredo <jasataco@gmail.com>
Co-authored-by: Andrea Bedini <andrea.bedini@tweag.io>
Co-authored-by: Andrea Bedini <andrea@andreabedini.com>

* Note how to do "not equal" with constraints

* Use comma with then

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

* Use narrow rather than upset

* Say something about hackage deprecations

* Fix AutogenModulesToggling test

By converting this to a setupTest we use the in-tree Cabal library
rather than relying on a proxy of the GHC version to provide the right
Cabal library version.

Supersedes haskell#9398

* Require version 3,11 of Cabal to support --semaphore flag

Fixes haskell#9197

* Add dependencies used by `PackageTests` to exe:cabal-tests

The runner allows the tests to use extra dependencies and the custom Prelude
from 'cabal-testsuite'.
However, if the tests use a dependency, say 'directory', and there are two
packages with the same unit id available in the store, the test fails since
it doesn't know which one to pick.
By including an extra dependency to directory, we force the test runner to
use a specific version directory, fixing the test failure.

* Use Paths_cabal_install for cabal-install version number (haskell#9421)

* Use PackageInfo for cabal-install version number

* Use Paths_cabal_install instead

* Adjust documentation

---------

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

* Document --profiling-detail in setup-commands.

Fixes haskell#9182

* Add test requirement to PR template

Adding test becomes a checkmark instead of “bonus points”.

* A 'cabal path' command. (haskell#8879)

* Add a 'cabal path' command.

* Formatting fix.

* Another formatting fix.

* Categorise "cabal path" as global command.

* Allow individual paths to be printed.

* Less duplication.

* Add config-file to "cabal path".

* Use sum type instead of strings.

* cabal path: support --installdir.

* Add documentation.

* Better text.

* Formatting.

* Add some tests.

* Improve tests.

* Add changelog entry.

* Mention "cabal path" in directory documentation.

---------

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

* Reimplement `cabal check` (haskell#8427)

* Fix Semigroup target instance

When two target names are the same, `mappend`ing them should not
error but just pick the first name.

* Add `desugarBuildToolSimple`

* Reimplement cabal check

* Reorder test output

* Fix autogen modules tests .cabal files

* Add a number of tests

* Add test for haskell#7423

i.e. Do not warn on -O2 if under off-by-default package configuration
flag conditional.

* Add a regression for:

    * Add another -WErrr test
        This is to make sure we do *not* report it if it is under
        a user, off-by-default flag.
    * Add test for non manual user flags.
    * Add “absolute path in extra-lib-dirs” test
    * Add if/else test
    * Add “dircheck on abspath” check
    * Add Package version internal test
    * Add PackageVersionsStraddle test

* Add changelog for haskell#8427

* Integrate various reviews

* Integrate Artem’s review

(review) Clarify `combineNames` documentation

By explaining the way it operates (working if the two names are equal
or one is empty) and renaming the function from `combineName` to
`combineNames`.

(review) Use guards instead of if/then/else

(review) Match inside argument list

(review) Replace “white” with “allow”

(review) Fix typo in comment

(review) Fix typo in Check module documentation

(review) Harmonise indentation for `data` decls

First field goes in a new line than the data constructor, so we
have more space.

(review) Rename `Prim` module to `Types`

(review) Add checkPackageFilesGPD

`checkPackageFiles` — which works on PD — was used to perform IO. We
introduce a function that does the same thing but works on GPD (which
is more principled).

`checkPackageFiles` cannot just be removed, since it is part of the
interface of Distribution.PackageDescription.Check. Deprecation can
be planned once “new check” is up and running.

* Integrate Andreas’ review

(review) Add named section to missing upper bound check

“miss upper bound” checks will now list target type and name (“On
executable 'myexe', these packages miss upper bounds”) for easier
fixing by the user.

(review) remove `cabal gen-bounds` suggestion

Reasonable as `cabal gen-bounds` is stricter than `cabal check`, see
haskell#8427 (comment)
Once `gen-bounds` behaves in line with `check` we can readd the
suggestion.

(review) Do not warn on shared bounds

When a target which depends on an internal library shares some
dependencies with the latter, do not warn on upper bounds.

An example is clearer

    library
     build-depends: text < 5
    ⁝
     build-depends: myPackage,        ← no warning, internal
                    text,             ← no warning, shared bound
                    monadacme         ← warning!

* Integrate Artem’s review /II

(review) Split Check.hs

Check.hs has been split in multiple file, each une sub 1000 lines:

Check              857 lines
Check.Common       147 lines
Check.Conditional  204 lines
Check.Monad        352 lines
Check.Paths        387 lines
Check.Target       765 lines
Check.Warning      865 lines

Migration guide:
- Check              GPD/PD checks plus work-tree checks.
- Check.Common       common types and functions that are
                     *not* part of monadic checking setup.
- Check.Conditional  checks on CondTree and related matter
                     (variables, duplicate modules).
- Check.Monad        Backbone of the checks, monadic inter-
                     face and related functions.
- Check.Paths        Checks on files, directories, globs.
- Check.Target       Checks on realised targets (libraries,
                     executables, benchmarks, testsuites).
- Check.Warning      Datatypes and strings for warnings
                     and severities.

(review) remove useless section header

(review) Fix typo

(review) Add warnings documentation (list)

For each warning, we document constructor/brief description
in the manual.  This might not be much useful as not but it
will come handy when introducing `--ignore=WARN` and similar
flags.

* (review Andreas) Clarify CheckExplanation comment

Whoever modifies `CheckExplanation` data constructors needs to be
aware that the documentation in  doc/cabal-commands.rst  has to be
updated too.

* Move internal Check modules to `other-modules`

No need to expose Distribution.PackageDescription.Check.*
to the world. API for checking, for cabal-install and other
tools, should be in Distribution.PackageDescription.Check.

* Make fourmolu happy

Cabal codebase has now a formatter/style standard (see haskell#8950).

“Ravioli ravioli, give me the formuoli”

* Do not check for OptO in scripts

See haskell#8963 for reason and clarification requests.

* Remove useless PackageId parameter

It is now in the Reader part of CheckM monad.

* Do not check PVP on internal targets

Internal: testsuite, benchmark.
See haskell#8361.

* Make hlint happy

* Fix haskell#9122

When checking internal version ranges, we need to make sure we
are not mistaking a libraries with the same name but from different
packages. See haskell#9132.

* Fix grammar

neither…nor, completing what done in haskell#9162

* Integrate Brandon’s review: grammar

* Remove unnecessary `-fvia-C` check

Brandon’s review/II.

---------

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

* ci: Enable windows tests for 9.6.3

There were two failing tests:

1. CCompilerOverride, was attempting to use gcc.exe rather than
   clang.exe without also overriding the C options which led to
   incorrect options being passed to gcc.exe. The fix is to override to
   clang.exe on ghc-9.4 or newer.
2. ForeignLibs exposes a bug in GHC
   (https://gitlab.haskell.org/ghc/ghc/-/issues/24185) and hence is
   skipped for GHCs newer than 9.4 where it was first introduced.

Towards fixing haskell#8451, we just need to fix the shared library issue now.

* testsuite: Be explicit about runtime test dependencies

Issue haskell#8356 reports occasional errors from running the testsuite about
multiple package versions available. This stems from the invokation of
`runghc` not being explicit about all dependencies of the testsuite.

The solution is provide a component in the cabal file which is explicit
about which packages the tests can depend on. This component has a
build-depends section which lists all the dependencies that the tests
require.

It would be better if this component was a library component but we
can't do this with a Custom setup because of limitations to do with
per-component builds.

Then we also enable `-hide-all-packages`, so the dependency will not be
available if it is not explicitly listed as a dependency.

You could also imagine a future where the Setup.hs script found the test
files and compiled a single executable which would run all the tests,
rather than invoking runghc on each one individually.

Fixes haskell#8356

* hurd: Enable using $ORIGIN in RPATH

GNU/Hurd fully supports RPATH and the $ORIGIN development, and we indeed
want to use it for relocatable installations shipped in Debian GNU/Hurd.

* Fix the platform string for GNU/Hurd

Since version 9.4.7-1, ghc fails to build on the GNU/Hurd port of Debian,
see

https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=hurd-i386&ver=9.4.7-1&stamp=1697717885&raw=0

Error, rule finished running but did not produce file:
  _build/stage0/lib/i386-gnu-ghc-9.4.6/ghc-boot-th-9.4.7/libHSghc-boot-th-9.4.7.a

and indeed, what did get produce was rather
_build/stage0/lib/i386-hurd-ghc-9.4.6/ghc-boot-th-9.4.7/libHSghc-boot-th-9.4.7.a
(i386-hurd instead of i386-gnu).

This is due to confusion between hurd and gnu in various places.  Apparently
previous versions of ghc were using gnu for the GNU/Hurd port, and thus
putting libraries etc. in i386-gnu. So we have to follow the existing
practice.

* Fix configuation of ldProgram

Standard GNU `ld` ues `--relocatable` while `ld.gold` uses a `-relocatable`
flag (with a single `-`). Code will now detect both versions.

* Chain configuration of ldProgram

`ldProgram` gets configured in two places, a seemingly default and
a GHC specific version. The later needs to be updated so that it
first calls the default configuration and then the new GHC version.

* Use linker capability detection to improve linker use

The function `comperSupportsGhciLibs` has been renamed to
`linkerSupportsGhciLibs` because its about the linker not the compiler.

The function `comperSupportsGhciLibs` was using the compiler version
as a proxy for whether the linker supports relocatable objects. Now
support for relocatable objects is detected by running the linker.

* add `merge+no rebase`

and a few typos while reviewing

* Add support for 64-bit SPARC as a separate architecture

Previously, sparc64 was defined as an alias for the 32-bit SPARC
architecture which was true while SPARC mainland was mostly 32
bits. More recently, 64-bit SPARC has become a port of its own,
so it needs to be treated as a separate architecture.

* Remove debug-conflict-sets flag from solver package

Fixes haskell#8937.

The debug-conflict-sets build flag probably hasn't been used for a long time,
and it isn't currently tested. This commit removes the flag, converts the
ConflictSet type back to a newtype, and removes an unnecessary instance.

* Finish improvements to the CI configuration for documentation changes (haskell#9460)

* Add bootstrap postjob to CI config

Add a new job to the bootstrap.yml GitHub action config.
This job succeeds if, and only if, all the other bootstrap
jobs succeed.

* Do not run bootstrap CI jobs for documentation changes

The approach was already introduced in haskell#9355 for the validate jobs.
This commit introduces the same change also for the bootstrap jobs.

* Also ignore CONTRIBUTING.md and README.md in CI

We do not run the entire CI suite for documentation changes.
Previously, only changes which were restricted to the 'docs/'
subdirectory were considered to be documentation changes.
With this commit we also recognize changes to README.md and
CONTRIBUTING.md as documentation changes.

* Document improved CI for documentation in CONTRIBUTING.md

The CONTRIBUTING.md file now mentions that documentation changes
do not waste expensive CI resources.

* Recognize all README.md in subdirs as documentation

Expensive CI jobs should not run on changes which affect only
README.md files.

* formatting: Add style-commit makefile target

This target allows you to format a range of commits, for example:

```
make style-commit COMMIT=HEAD~1
> Last commit is formatted
make style-commit COMMIT=abcde
> Commits between HEAD and abcde are formatted
```

* Fix assertion failure when combining build-tool-depends and --enable-documentation

The `setDocumentation` function was modifying the elaborated package
after the hash was computed. This led to the assertion failing as the
computed hash was different to what was computed in the initial install
plan.

Therefore in order to fix this we either needed to:

1. Set elabBuildHaddocks = False at the point where the hash is
   initially computed.
2. Verify that elabBuildHaddocks = True will not lead to unexpected
   results.

The latter has been implemented.

The elabBuildHaddocks option is only consulted in
`hasValidHaddockTargets`, at which point documentation building the
executable component is disabled because elabHaddockExecutables is
False.

In the added test we ensure this by checking that we didn't build
documentation for the executable which is built because of
build-tool-depends.

Fixes haskell#6006 haskell#8313

* testsuite: Improve error message in findDependencyInStore

* Only move code to Simple/GHC/Build*

* CPP mingw32_HOST_OS for more imports

* cabal-install-solver: fix pkgconf 1.9 --modversion regression

Check that the numbers of *versions* output is equal to the number of pkgconf's

fixes haskell#8923

The pkgconf behavior was reverted upstream in 2.0

(this should cover the case too of checking that equal pkgList lines are output also)

* External commands: Add tests for haskell#9402 haskell#9403 haskell#9404

This adds 4 tests which test the new external commands feature:

* ExternalCommand - Tests the expected usage of external command invoked
  via cabal-install
* ExternalCommandSetup - Tests that the ./Setup interface does not
  support external commands (haskell#9403)
* ExternalCommandEnv - Tests that environment variables are set and
  preserved appropiately  (haskell#9402)
* ExternalCommandHelp - Test that `cabal help <cmd>` is interpreted appropiately (haskell#9404)

* Finish off the external commands feature

* Remove 'CommandDelegate' in favour of abstracting the fallback in
  'commandsRun', there is a new variant 'commdandRunWithFallback' which
  takes a continuation
  - This restores the modularity between the `Cabal` library and
    `cabal-install` as now `Cabal` doesn't need to know anything about
    the external command interface.
  - Fixes haskell#9403
* Set the $CABAL environment variable to the current executable path
  - This allows external commands to be implemented by calling $CABAL,
    which is strongly preferred to linking against the Cabal library as
    there is no easy way to guantee your tool and `cabal-install` link
    against the same `Cabal` library.
  - Fixes haskell#9402
* Pass the name of the argument
  - This allows external commands to be implemented as symlinks to an
    executable, and multiple commands can be interpreted by the same
    executable.
  - Fixes haskell#9405
* `cabal help <cmd>` is interpreted as `cabal-<cmd> --help` for external
  commands.
  - This allows the `help` command to also work for external
  commands and hence they are better integrated into cabal-install.
  - Fixes haskell#9404

The tests are updated to test all these additions.

These features bring the external command interface up to par with the
cargo external command interface.

* Use Base16 hash for script path.

Issue haskell#9334 shows that `%` characters on Windows result in invalid
paths, also `/` characters on Linux create invalid paths.

This changes from using base64 to using base16 with the same length
we use for unit-ids.

* Migrate to haskell-actions/setup

As of 2023-09-09, haskell/action/setup is no longer maintained.

The comment

  # latest is mandatory for cabal-testsuite, see haskell#8133

is removed; as the validate job was already fixing a version of cabal-install.

* testsuite: Introduce Cabal-tests library for common testsuite functions

I noticed that Distribution.Utils.TempTestDir was only used in the
testsuite but defined in the Cabal library. Rather than expose this in
the public interface of the `Cabal` library, it is cleaner to refactor
it into a separate library (`Cabal-tests`) which can be used by any
testsuite component.

Also, in future it gives a clearer place to put utility functions which
need to be shared across the testsuite but not exposed in Cabal.
Cabal-tests can also freely add dependencies (such as exceptions) which
we might want to avoid adding to the Cabal library.

Fixes haskell#9453

* GHC 9.8 compat: pacify -Wx-partial

* GHC 9.8 compat: update hashes of data structures as computed by Structured

It seems, GHC 9.8 changed something in the code generation for data types.
Structured class is supposed to catch such cases.

* GHC 9.8 compat: bump base, update Unknown GHC

And bump Cabal's "supported version" of GHC

* CI: GHC 9.8

* merge master

* Hackage should be capitalized

---------

Co-authored-by: Artem Pelenitsyn <a.pelenitsyn@gmail.com>
Co-authored-by: Bryan Richter <bryan@haskell.foundation>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Co-authored-by: Phil de Joux <philderbeast@gmail.com>
Co-authored-by: Yvan Sraka <yvan@sraka.xyz>
Co-authored-by: Andreas Abel <andreas.abel@ifi.lmu.de>
Co-authored-by: Jens Petersen <petersen@redhat.com>
Co-authored-by: Andrea Bedini <andrea.bedini@tweag.io>
Co-authored-by: Hamish Mackenzie <Hamish.K.Mackenzie@gmail.com>
Co-authored-by: Malte Neuss <malteneuss@users.noreply.github.com>
Co-authored-by: Bodigrim <andrew.lelechenko@gmail.com>
Co-authored-by: David Binder <david.binder@uni-tuebingen.de>
Co-authored-by: David Binder <binderd@informatik.uni-tuebingen.de>
Co-authored-by: Javier Sagredo <jasataco@gmail.com>
Co-authored-by: Andrea Bedini <andrea@andreabedini.com>
Co-authored-by: Matthew Pickering <matthewtpickering@gmail.com>
Co-authored-by: Fendor <power.walross@gmail.com>
Co-authored-by: Hécate Moonlight <Kleidukos@users.noreply.github.com>
Co-authored-by: Andreas Klebinger <klebinger.andreas@gmx.at>
Co-authored-by: Francesco Ariis <fa-ml@ariis.it>
Co-authored-by: Troels Henriksen <athas@sigkill.dk>
Co-authored-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Co-authored-by: Erik de Castro Lopo <erikd@mega-nerd.com>
Co-authored-by: brandon s allbery kf8nh <allbery.b@gmail.com>
Co-authored-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Co-authored-by: Kristen Kozak <grayjay@wordroute.com>
Co-authored-by: Javier Sagredo <javier.sagredo@iohk.io>
alt-romes pushed a commit to alt-romes/cabal that referenced this issue Dec 4, 2023
…ange only. (haskell#9386)

* add more breadcrumbs for how to use remote packages.

* Hackage should be capitalized

* Update doc/cabal-project.rst

reword.

* Update doc/cabal-project.rst

reword.

* Update doc/cabal-project.rst

clearer.

* Update doc/cabal-project.rst

clearer!

* Update doc/cabal-project.rst

good mechanical description.

* wrap.

* Update doc/cabal-project.rst

add missing double ticks.

* clarify english, and follow a linguistic pattern better.

* Update doc/cabal-project.rst

* doc: render math with HTML to make it selectable (fix haskell#8453) (haskell#9361)

* doc: render math with HTML to make it selectable (fix haskell#8453)

* Update doc/conf.py

Co-authored-by: Bryan Richter <bryan@haskell.foundation>

---------

Co-authored-by: Bryan Richter <bryan@haskell.foundation>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

* Avoid double space in "Executing install plan ..."

* Add a change log entry for double space avoidance

* Ignore CmmSourcesExe Demo

Ignore because it warns about missing MachDeps.h

* [cabal-7825] Implement external command system

Fix haskell#2349 and haskell#7825

* Bump to latest dependencies for GHC 9.8.1

* cabal.project: clean out obsolete `allow-newer`s

* update GH validate workflow to ghc 9.2.8, 9.4.7, 9.6.3

* Revert haskell#3639 (Don't pass -package-db and -package flags to --abi-hash) (haskell#9384)

* Revert haskell#3639 (Don't pass -package-db and -package flags to --abi-hash)

With ghc>=9.6 `ghc --abi-hash` initialises the plugins so it will fail
if a cabal file specifies `ghc-options: -fplugin=Foo`.

Closes: haskell#9375

* Also revert in GHC.hs

---------

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

* Use the newer haskell-actions organisation

* Restructure Cabal documentation top-level parts

The goal is for users to easier find pages for typical problems through search engines and page navigation.
- The top-level layout is based on the popular documentation structure by https://documentation.divio.com/ to give a
   clear structure to users and future documentation contributors:
  * Guides: Present a solution to a single, atomic, typical user problem.
  * Reference: Describe user API (CLI fields, syntax etc) with technical rigour and completeness.
  * Explanation: Discuss background information, scope, design decisions etc.
- Move existing documentation roughly into these categories with minimal editing as the basis for further editing.
- Rename guide titles to mention how-to for improving SEO.
- Rename some files to improve SEO since that name becomes part of the URL (often called slug).
  Important page keywords should appear in the slug as well to make pages rank higher in search engines.

* Rename master_doc to root_doc (changed in version 4.0 of Sphynx)

* Add instance Ord for Field, FieldLine, SectionArg and Name

* Do not run CI for documentation changes

The github workflows are not run if the
changes are completely contained within
the doc/ subdirectory. The only exception
is the users-guide.yml github action.

* Move Backpack section to user guides

* Remove TBW virtual modules section

* Add reinstall test to LinkerOptions/NonignoredConfigs

* Record install options

* Reject index-states after last known index-state (haskell#8944)

Co-authored-by: Javier Sagredo <jasataco@gmail.com>
Co-authored-by: Andrea Bedini <andrea.bedini@tweag.io>
Co-authored-by: Andrea Bedini <andrea@andreabedini.com>

* Note how to do "not equal" with constraints

* Use comma with then

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

* Use narrow rather than upset

* Say something about hackage deprecations

* Fix AutogenModulesToggling test

By converting this to a setupTest we use the in-tree Cabal library
rather than relying on a proxy of the GHC version to provide the right
Cabal library version.

Supersedes haskell#9398

* Require version 3,11 of Cabal to support --semaphore flag

Fixes haskell#9197

* Add dependencies used by `PackageTests` to exe:cabal-tests

The runner allows the tests to use extra dependencies and the custom Prelude
from 'cabal-testsuite'.
However, if the tests use a dependency, say 'directory', and there are two
packages with the same unit id available in the store, the test fails since
it doesn't know which one to pick.
By including an extra dependency to directory, we force the test runner to
use a specific version directory, fixing the test failure.

* Use Paths_cabal_install for cabal-install version number (haskell#9421)

* Use PackageInfo for cabal-install version number

* Use Paths_cabal_install instead

* Adjust documentation

---------

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

* Document --profiling-detail in setup-commands.

Fixes haskell#9182

* Add test requirement to PR template

Adding test becomes a checkmark instead of “bonus points”.

* A 'cabal path' command. (haskell#8879)

* Add a 'cabal path' command.

* Formatting fix.

* Another formatting fix.

* Categorise "cabal path" as global command.

* Allow individual paths to be printed.

* Less duplication.

* Add config-file to "cabal path".

* Use sum type instead of strings.

* cabal path: support --installdir.

* Add documentation.

* Better text.

* Formatting.

* Add some tests.

* Improve tests.

* Add changelog entry.

* Mention "cabal path" in directory documentation.

---------

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

* Reimplement `cabal check` (haskell#8427)

* Fix Semigroup target instance

When two target names are the same, `mappend`ing them should not
error but just pick the first name.

* Add `desugarBuildToolSimple`

* Reimplement cabal check

* Reorder test output

* Fix autogen modules tests .cabal files

* Add a number of tests

* Add test for haskell#7423

i.e. Do not warn on -O2 if under off-by-default package configuration
flag conditional.

* Add a regression for:

    * Add another -WErrr test
        This is to make sure we do *not* report it if it is under
        a user, off-by-default flag.
    * Add test for non manual user flags.
    * Add “absolute path in extra-lib-dirs” test
    * Add if/else test
    * Add “dircheck on abspath” check
    * Add Package version internal test
    * Add PackageVersionsStraddle test

* Add changelog for haskell#8427

* Integrate various reviews

* Integrate Artem’s review

(review) Clarify `combineNames` documentation

By explaining the way it operates (working if the two names are equal
or one is empty) and renaming the function from `combineName` to
`combineNames`.

(review) Use guards instead of if/then/else

(review) Match inside argument list

(review) Replace “white” with “allow”

(review) Fix typo in comment

(review) Fix typo in Check module documentation

(review) Harmonise indentation for `data` decls

First field goes in a new line than the data constructor, so we
have more space.

(review) Rename `Prim` module to `Types`

(review) Add checkPackageFilesGPD

`checkPackageFiles` — which works on PD — was used to perform IO. We
introduce a function that does the same thing but works on GPD (which
is more principled).

`checkPackageFiles` cannot just be removed, since it is part of the
interface of Distribution.PackageDescription.Check. Deprecation can
be planned once “new check” is up and running.

* Integrate Andreas’ review

(review) Add named section to missing upper bound check

“miss upper bound” checks will now list target type and name (“On
executable 'myexe', these packages miss upper bounds”) for easier
fixing by the user.

(review) remove `cabal gen-bounds` suggestion

Reasonable as `cabal gen-bounds` is stricter than `cabal check`, see
haskell#8427 (comment)
Once `gen-bounds` behaves in line with `check` we can readd the
suggestion.

(review) Do not warn on shared bounds

When a target which depends on an internal library shares some
dependencies with the latter, do not warn on upper bounds.

An example is clearer

    library
     build-depends: text < 5
    ⁝
     build-depends: myPackage,        ← no warning, internal
                    text,             ← no warning, shared bound
                    monadacme         ← warning!

* Integrate Artem’s review /II

(review) Split Check.hs

Check.hs has been split in multiple file, each une sub 1000 lines:

Check              857 lines
Check.Common       147 lines
Check.Conditional  204 lines
Check.Monad        352 lines
Check.Paths        387 lines
Check.Target       765 lines
Check.Warning      865 lines

Migration guide:
- Check              GPD/PD checks plus work-tree checks.
- Check.Common       common types and functions that are
                     *not* part of monadic checking setup.
- Check.Conditional  checks on CondTree and related matter
                     (variables, duplicate modules).
- Check.Monad        Backbone of the checks, monadic inter-
                     face and related functions.
- Check.Paths        Checks on files, directories, globs.
- Check.Target       Checks on realised targets (libraries,
                     executables, benchmarks, testsuites).
- Check.Warning      Datatypes and strings for warnings
                     and severities.

(review) remove useless section header

(review) Fix typo

(review) Add warnings documentation (list)

For each warning, we document constructor/brief description
in the manual.  This might not be much useful as not but it
will come handy when introducing `--ignore=WARN` and similar
flags.

* (review Andreas) Clarify CheckExplanation comment

Whoever modifies `CheckExplanation` data constructors needs to be
aware that the documentation in  doc/cabal-commands.rst  has to be
updated too.

* Move internal Check modules to `other-modules`

No need to expose Distribution.PackageDescription.Check.*
to the world. API for checking, for cabal-install and other
tools, should be in Distribution.PackageDescription.Check.

* Make fourmolu happy

Cabal codebase has now a formatter/style standard (see haskell#8950).

“Ravioli ravioli, give me the formuoli”

* Do not check for OptO in scripts

See haskell#8963 for reason and clarification requests.

* Remove useless PackageId parameter

It is now in the Reader part of CheckM monad.

* Do not check PVP on internal targets

Internal: testsuite, benchmark.
See haskell#8361.

* Make hlint happy

* Fix haskell#9122

When checking internal version ranges, we need to make sure we
are not mistaking a libraries with the same name but from different
packages. See haskell#9132.

* Fix grammar

neither…nor, completing what done in haskell#9162

* Integrate Brandon’s review: grammar

* Remove unnecessary `-fvia-C` check

Brandon’s review/II.

---------

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

* ci: Enable windows tests for 9.6.3

There were two failing tests:

1. CCompilerOverride, was attempting to use gcc.exe rather than
   clang.exe without also overriding the C options which led to
   incorrect options being passed to gcc.exe. The fix is to override to
   clang.exe on ghc-9.4 or newer.
2. ForeignLibs exposes a bug in GHC
   (https://gitlab.haskell.org/ghc/ghc/-/issues/24185) and hence is
   skipped for GHCs newer than 9.4 where it was first introduced.

Towards fixing haskell#8451, we just need to fix the shared library issue now.

* testsuite: Be explicit about runtime test dependencies

Issue haskell#8356 reports occasional errors from running the testsuite about
multiple package versions available. This stems from the invokation of
`runghc` not being explicit about all dependencies of the testsuite.

The solution is provide a component in the cabal file which is explicit
about which packages the tests can depend on. This component has a
build-depends section which lists all the dependencies that the tests
require.

It would be better if this component was a library component but we
can't do this with a Custom setup because of limitations to do with
per-component builds.

Then we also enable `-hide-all-packages`, so the dependency will not be
available if it is not explicitly listed as a dependency.

You could also imagine a future where the Setup.hs script found the test
files and compiled a single executable which would run all the tests,
rather than invoking runghc on each one individually.

Fixes haskell#8356

* hurd: Enable using $ORIGIN in RPATH

GNU/Hurd fully supports RPATH and the $ORIGIN development, and we indeed
want to use it for relocatable installations shipped in Debian GNU/Hurd.

* Fix the platform string for GNU/Hurd

Since version 9.4.7-1, ghc fails to build on the GNU/Hurd port of Debian,
see

https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=hurd-i386&ver=9.4.7-1&stamp=1697717885&raw=0

Error, rule finished running but did not produce file:
  _build/stage0/lib/i386-gnu-ghc-9.4.6/ghc-boot-th-9.4.7/libHSghc-boot-th-9.4.7.a

and indeed, what did get produce was rather
_build/stage0/lib/i386-hurd-ghc-9.4.6/ghc-boot-th-9.4.7/libHSghc-boot-th-9.4.7.a
(i386-hurd instead of i386-gnu).

This is due to confusion between hurd and gnu in various places.  Apparently
previous versions of ghc were using gnu for the GNU/Hurd port, and thus
putting libraries etc. in i386-gnu. So we have to follow the existing
practice.

* Fix configuation of ldProgram

Standard GNU `ld` ues `--relocatable` while `ld.gold` uses a `-relocatable`
flag (with a single `-`). Code will now detect both versions.

* Chain configuration of ldProgram

`ldProgram` gets configured in two places, a seemingly default and
a GHC specific version. The later needs to be updated so that it
first calls the default configuration and then the new GHC version.

* Use linker capability detection to improve linker use

The function `comperSupportsGhciLibs` has been renamed to
`linkerSupportsGhciLibs` because its about the linker not the compiler.

The function `comperSupportsGhciLibs` was using the compiler version
as a proxy for whether the linker supports relocatable objects. Now
support for relocatable objects is detected by running the linker.

* add `merge+no rebase`

and a few typos while reviewing

* Add support for 64-bit SPARC as a separate architecture

Previously, sparc64 was defined as an alias for the 32-bit SPARC
architecture which was true while SPARC mainland was mostly 32
bits. More recently, 64-bit SPARC has become a port of its own,
so it needs to be treated as a separate architecture.

* Remove debug-conflict-sets flag from solver package

Fixes haskell#8937.

The debug-conflict-sets build flag probably hasn't been used for a long time,
and it isn't currently tested. This commit removes the flag, converts the
ConflictSet type back to a newtype, and removes an unnecessary instance.

* Finish improvements to the CI configuration for documentation changes (haskell#9460)

* Add bootstrap postjob to CI config

Add a new job to the bootstrap.yml GitHub action config.
This job succeeds if, and only if, all the other bootstrap
jobs succeed.

* Do not run bootstrap CI jobs for documentation changes

The approach was already introduced in haskell#9355 for the validate jobs.
This commit introduces the same change also for the bootstrap jobs.

* Also ignore CONTRIBUTING.md and README.md in CI

We do not run the entire CI suite for documentation changes.
Previously, only changes which were restricted to the 'docs/'
subdirectory were considered to be documentation changes.
With this commit we also recognize changes to README.md and
CONTRIBUTING.md as documentation changes.

* Document improved CI for documentation in CONTRIBUTING.md

The CONTRIBUTING.md file now mentions that documentation changes
do not waste expensive CI resources.

* Recognize all README.md in subdirs as documentation

Expensive CI jobs should not run on changes which affect only
README.md files.

* formatting: Add style-commit makefile target

This target allows you to format a range of commits, for example:

```
make style-commit COMMIT=HEAD~1
> Last commit is formatted
make style-commit COMMIT=abcde
> Commits between HEAD and abcde are formatted
```

* Fix assertion failure when combining build-tool-depends and --enable-documentation

The `setDocumentation` function was modifying the elaborated package
after the hash was computed. This led to the assertion failing as the
computed hash was different to what was computed in the initial install
plan.

Therefore in order to fix this we either needed to:

1. Set elabBuildHaddocks = False at the point where the hash is
   initially computed.
2. Verify that elabBuildHaddocks = True will not lead to unexpected
   results.

The latter has been implemented.

The elabBuildHaddocks option is only consulted in
`hasValidHaddockTargets`, at which point documentation building the
executable component is disabled because elabHaddockExecutables is
False.

In the added test we ensure this by checking that we didn't build
documentation for the executable which is built because of
build-tool-depends.

Fixes haskell#6006 haskell#8313

* testsuite: Improve error message in findDependencyInStore

* Only move code to Simple/GHC/Build*

* CPP mingw32_HOST_OS for more imports

* cabal-install-solver: fix pkgconf 1.9 --modversion regression

Check that the numbers of *versions* output is equal to the number of pkgconf's

fixes haskell#8923

The pkgconf behavior was reverted upstream in 2.0

(this should cover the case too of checking that equal pkgList lines are output also)

* External commands: Add tests for haskell#9402 haskell#9403 haskell#9404

This adds 4 tests which test the new external commands feature:

* ExternalCommand - Tests the expected usage of external command invoked
  via cabal-install
* ExternalCommandSetup - Tests that the ./Setup interface does not
  support external commands (haskell#9403)
* ExternalCommandEnv - Tests that environment variables are set and
  preserved appropiately  (haskell#9402)
* ExternalCommandHelp - Test that `cabal help <cmd>` is interpreted appropiately (haskell#9404)

* Finish off the external commands feature

* Remove 'CommandDelegate' in favour of abstracting the fallback in
  'commandsRun', there is a new variant 'commdandRunWithFallback' which
  takes a continuation
  - This restores the modularity between the `Cabal` library and
    `cabal-install` as now `Cabal` doesn't need to know anything about
    the external command interface.
  - Fixes haskell#9403
* Set the $CABAL environment variable to the current executable path
  - This allows external commands to be implemented by calling $CABAL,
    which is strongly preferred to linking against the Cabal library as
    there is no easy way to guantee your tool and `cabal-install` link
    against the same `Cabal` library.
  - Fixes haskell#9402
* Pass the name of the argument
  - This allows external commands to be implemented as symlinks to an
    executable, and multiple commands can be interpreted by the same
    executable.
  - Fixes haskell#9405
* `cabal help <cmd>` is interpreted as `cabal-<cmd> --help` for external
  commands.
  - This allows the `help` command to also work for external
  commands and hence they are better integrated into cabal-install.
  - Fixes haskell#9404

The tests are updated to test all these additions.

These features bring the external command interface up to par with the
cargo external command interface.

* Use Base16 hash for script path.

Issue haskell#9334 shows that `%` characters on Windows result in invalid
paths, also `/` characters on Linux create invalid paths.

This changes from using base64 to using base16 with the same length
we use for unit-ids.

* Migrate to haskell-actions/setup

As of 2023-09-09, haskell/action/setup is no longer maintained.

The comment

  # latest is mandatory for cabal-testsuite, see haskell#8133

is removed; as the validate job was already fixing a version of cabal-install.

* testsuite: Introduce Cabal-tests library for common testsuite functions

I noticed that Distribution.Utils.TempTestDir was only used in the
testsuite but defined in the Cabal library. Rather than expose this in
the public interface of the `Cabal` library, it is cleaner to refactor
it into a separate library (`Cabal-tests`) which can be used by any
testsuite component.

Also, in future it gives a clearer place to put utility functions which
need to be shared across the testsuite but not exposed in Cabal.
Cabal-tests can also freely add dependencies (such as exceptions) which
we might want to avoid adding to the Cabal library.

Fixes haskell#9453

* GHC 9.8 compat: pacify -Wx-partial

* GHC 9.8 compat: update hashes of data structures as computed by Structured

It seems, GHC 9.8 changed something in the code generation for data types.
Structured class is supposed to catch such cases.

* GHC 9.8 compat: bump base, update Unknown GHC

And bump Cabal's "supported version" of GHC

* CI: GHC 9.8

* merge master

* Hackage should be capitalized

---------

Co-authored-by: Artem Pelenitsyn <a.pelenitsyn@gmail.com>
Co-authored-by: Bryan Richter <bryan@haskell.foundation>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Co-authored-by: Phil de Joux <philderbeast@gmail.com>
Co-authored-by: Yvan Sraka <yvan@sraka.xyz>
Co-authored-by: Andreas Abel <andreas.abel@ifi.lmu.de>
Co-authored-by: Jens Petersen <petersen@redhat.com>
Co-authored-by: Andrea Bedini <andrea.bedini@tweag.io>
Co-authored-by: Hamish Mackenzie <Hamish.K.Mackenzie@gmail.com>
Co-authored-by: Malte Neuss <malteneuss@users.noreply.github.com>
Co-authored-by: Bodigrim <andrew.lelechenko@gmail.com>
Co-authored-by: David Binder <david.binder@uni-tuebingen.de>
Co-authored-by: David Binder <binderd@informatik.uni-tuebingen.de>
Co-authored-by: Javier Sagredo <jasataco@gmail.com>
Co-authored-by: Andrea Bedini <andrea@andreabedini.com>
Co-authored-by: Matthew Pickering <matthewtpickering@gmail.com>
Co-authored-by: Fendor <power.walross@gmail.com>
Co-authored-by: Hécate Moonlight <Kleidukos@users.noreply.github.com>
Co-authored-by: Andreas Klebinger <klebinger.andreas@gmx.at>
Co-authored-by: Francesco Ariis <fa-ml@ariis.it>
Co-authored-by: Troels Henriksen <athas@sigkill.dk>
Co-authored-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Co-authored-by: Erik de Castro Lopo <erikd@mega-nerd.com>
Co-authored-by: brandon s allbery kf8nh <allbery.b@gmail.com>
Co-authored-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Co-authored-by: Kristen Kozak <grayjay@wordroute.com>
Co-authored-by: Javier Sagredo <javier.sagredo@iohk.io>
erikd added a commit to erikd/cabal that referenced this issue Apr 22, 2024
…ange only. (haskell#9386)

* add more breadcrumbs for how to use remote packages.

* Hackage should be capitalized

* Update doc/cabal-project.rst

reword.

* Update doc/cabal-project.rst

reword.

* Update doc/cabal-project.rst

clearer.

* Update doc/cabal-project.rst

clearer!

* Update doc/cabal-project.rst

good mechanical description.

* wrap.

* Update doc/cabal-project.rst

add missing double ticks.

* clarify english, and follow a linguistic pattern better.

* Update doc/cabal-project.rst

* doc: render math with HTML to make it selectable (fix haskell#8453) (haskell#9361)

* doc: render math with HTML to make it selectable (fix haskell#8453)

* Update doc/conf.py

Co-authored-by: Bryan Richter <bryan@haskell.foundation>

---------

Co-authored-by: Bryan Richter <bryan@haskell.foundation>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

* Avoid double space in "Executing install plan ..."

* Add a change log entry for double space avoidance

* Ignore CmmSourcesExe Demo

Ignore because it warns about missing MachDeps.h

* [cabal-7825] Implement external command system

Fix haskell#2349 and haskell#7825

* Bump to latest dependencies for GHC 9.8.1

* cabal.project: clean out obsolete `allow-newer`s

* update GH validate workflow to ghc 9.2.8, 9.4.7, 9.6.3

* Revert haskell#3639 (Don't pass -package-db and -package flags to --abi-hash) (haskell#9384)

* Revert haskell#3639 (Don't pass -package-db and -package flags to --abi-hash)

With ghc>=9.6 `ghc --abi-hash` initialises the plugins so it will fail
if a cabal file specifies `ghc-options: -fplugin=Foo`.

Closes: haskell#9375

* Also revert in GHC.hs

---------

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

* Use the newer haskell-actions organisation

* Restructure Cabal documentation top-level parts

The goal is for users to easier find pages for typical problems through search engines and page navigation.
- The top-level layout is based on the popular documentation structure by https://documentation.divio.com/ to give a
   clear structure to users and future documentation contributors:
  * Guides: Present a solution to a single, atomic, typical user problem.
  * Reference: Describe user API (CLI fields, syntax etc) with technical rigour and completeness.
  * Explanation: Discuss background information, scope, design decisions etc.
- Move existing documentation roughly into these categories with minimal editing as the basis for further editing.
- Rename guide titles to mention how-to for improving SEO.
- Rename some files to improve SEO since that name becomes part of the URL (often called slug).
  Important page keywords should appear in the slug as well to make pages rank higher in search engines.

* Rename master_doc to root_doc (changed in version 4.0 of Sphynx)

* Add instance Ord for Field, FieldLine, SectionArg and Name

* Do not run CI for documentation changes

The github workflows are not run if the
changes are completely contained within
the doc/ subdirectory. The only exception
is the users-guide.yml github action.

* Move Backpack section to user guides

* Remove TBW virtual modules section

* Add reinstall test to LinkerOptions/NonignoredConfigs

* Record install options

* Reject index-states after last known index-state (haskell#8944)

Co-authored-by: Javier Sagredo <jasataco@gmail.com>
Co-authored-by: Andrea Bedini <andrea.bedini@tweag.io>
Co-authored-by: Andrea Bedini <andrea@andreabedini.com>

* Note how to do "not equal" with constraints

* Use comma with then

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

* Use narrow rather than upset

* Say something about hackage deprecations

* Fix AutogenModulesToggling test

By converting this to a setupTest we use the in-tree Cabal library
rather than relying on a proxy of the GHC version to provide the right
Cabal library version.

Supersedes haskell#9398

* Require version 3,11 of Cabal to support --semaphore flag

Fixes haskell#9197

* Add dependencies used by `PackageTests` to exe:cabal-tests

The runner allows the tests to use extra dependencies and the custom Prelude
from 'cabal-testsuite'.
However, if the tests use a dependency, say 'directory', and there are two
packages with the same unit id available in the store, the test fails since
it doesn't know which one to pick.
By including an extra dependency to directory, we force the test runner to
use a specific version directory, fixing the test failure.

* Use Paths_cabal_install for cabal-install version number (haskell#9421)

* Use PackageInfo for cabal-install version number

* Use Paths_cabal_install instead

* Adjust documentation

---------

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

* Document --profiling-detail in setup-commands.

Fixes haskell#9182

* Add test requirement to PR template

Adding test becomes a checkmark instead of “bonus points”.

* A 'cabal path' command. (haskell#8879)

* Add a 'cabal path' command.

* Formatting fix.

* Another formatting fix.

* Categorise "cabal path" as global command.

* Allow individual paths to be printed.

* Less duplication.

* Add config-file to "cabal path".

* Use sum type instead of strings.

* cabal path: support --installdir.

* Add documentation.

* Better text.

* Formatting.

* Add some tests.

* Improve tests.

* Add changelog entry.

* Mention "cabal path" in directory documentation.

---------

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

* Reimplement `cabal check` (haskell#8427)

* Fix Semigroup target instance

When two target names are the same, `mappend`ing them should not
error but just pick the first name.

* Add `desugarBuildToolSimple`

* Reimplement cabal check

* Reorder test output

* Fix autogen modules tests .cabal files

* Add a number of tests

* Add test for haskell#7423

i.e. Do not warn on -O2 if under off-by-default package configuration
flag conditional.

* Add a regression for:

    * Add another -WErrr test
        This is to make sure we do *not* report it if it is under
        a user, off-by-default flag.
    * Add test for non manual user flags.
    * Add “absolute path in extra-lib-dirs” test
    * Add if/else test
    * Add “dircheck on abspath” check
    * Add Package version internal test
    * Add PackageVersionsStraddle test

* Add changelog for haskell#8427

* Integrate various reviews

* Integrate Artem’s review

(review) Clarify `combineNames` documentation

By explaining the way it operates (working if the two names are equal
or one is empty) and renaming the function from `combineName` to
`combineNames`.

(review) Use guards instead of if/then/else

(review) Match inside argument list

(review) Replace “white” with “allow”

(review) Fix typo in comment

(review) Fix typo in Check module documentation

(review) Harmonise indentation for `data` decls

First field goes in a new line than the data constructor, so we
have more space.

(review) Rename `Prim` module to `Types`

(review) Add checkPackageFilesGPD

`checkPackageFiles` — which works on PD — was used to perform IO. We
introduce a function that does the same thing but works on GPD (which
is more principled).

`checkPackageFiles` cannot just be removed, since it is part of the
interface of Distribution.PackageDescription.Check. Deprecation can
be planned once “new check” is up and running.

* Integrate Andreas’ review

(review) Add named section to missing upper bound check

“miss upper bound” checks will now list target type and name (“On
executable 'myexe', these packages miss upper bounds”) for easier
fixing by the user.

(review) remove `cabal gen-bounds` suggestion

Reasonable as `cabal gen-bounds` is stricter than `cabal check`, see
haskell#8427 (comment)
Once `gen-bounds` behaves in line with `check` we can readd the
suggestion.

(review) Do not warn on shared bounds

When a target which depends on an internal library shares some
dependencies with the latter, do not warn on upper bounds.

An example is clearer

    library
     build-depends: text < 5
    ⁝
     build-depends: myPackage,        ← no warning, internal
                    text,             ← no warning, shared bound
                    monadacme         ← warning!

* Integrate Artem’s review /II

(review) Split Check.hs

Check.hs has been split in multiple file, each une sub 1000 lines:

Check              857 lines
Check.Common       147 lines
Check.Conditional  204 lines
Check.Monad        352 lines
Check.Paths        387 lines
Check.Target       765 lines
Check.Warning      865 lines

Migration guide:
- Check              GPD/PD checks plus work-tree checks.
- Check.Common       common types and functions that are
                     *not* part of monadic checking setup.
- Check.Conditional  checks on CondTree and related matter
                     (variables, duplicate modules).
- Check.Monad        Backbone of the checks, monadic inter-
                     face and related functions.
- Check.Paths        Checks on files, directories, globs.
- Check.Target       Checks on realised targets (libraries,
                     executables, benchmarks, testsuites).
- Check.Warning      Datatypes and strings for warnings
                     and severities.

(review) remove useless section header

(review) Fix typo

(review) Add warnings documentation (list)

For each warning, we document constructor/brief description
in the manual.  This might not be much useful as not but it
will come handy when introducing `--ignore=WARN` and similar
flags.

* (review Andreas) Clarify CheckExplanation comment

Whoever modifies `CheckExplanation` data constructors needs to be
aware that the documentation in  doc/cabal-commands.rst  has to be
updated too.

* Move internal Check modules to `other-modules`

No need to expose Distribution.PackageDescription.Check.*
to the world. API for checking, for cabal-install and other
tools, should be in Distribution.PackageDescription.Check.

* Make fourmolu happy

Cabal codebase has now a formatter/style standard (see haskell#8950).

“Ravioli ravioli, give me the formuoli”

* Do not check for OptO in scripts

See haskell#8963 for reason and clarification requests.

* Remove useless PackageId parameter

It is now in the Reader part of CheckM monad.

* Do not check PVP on internal targets

Internal: testsuite, benchmark.
See haskell#8361.

* Make hlint happy

* Fix haskell#9122

When checking internal version ranges, we need to make sure we
are not mistaking a libraries with the same name but from different
packages. See haskell#9132.

* Fix grammar

neither…nor, completing what done in haskell#9162

* Integrate Brandon’s review: grammar

* Remove unnecessary `-fvia-C` check

Brandon’s review/II.

---------

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

* ci: Enable windows tests for 9.6.3

There were two failing tests:

1. CCompilerOverride, was attempting to use gcc.exe rather than
   clang.exe without also overriding the C options which led to
   incorrect options being passed to gcc.exe. The fix is to override to
   clang.exe on ghc-9.4 or newer.
2. ForeignLibs exposes a bug in GHC
   (https://gitlab.haskell.org/ghc/ghc/-/issues/24185) and hence is
   skipped for GHCs newer than 9.4 where it was first introduced.

Towards fixing haskell#8451, we just need to fix the shared library issue now.

* testsuite: Be explicit about runtime test dependencies

Issue haskell#8356 reports occasional errors from running the testsuite about
multiple package versions available. This stems from the invokation of
`runghc` not being explicit about all dependencies of the testsuite.

The solution is provide a component in the cabal file which is explicit
about which packages the tests can depend on. This component has a
build-depends section which lists all the dependencies that the tests
require.

It would be better if this component was a library component but we
can't do this with a Custom setup because of limitations to do with
per-component builds.

Then we also enable `-hide-all-packages`, so the dependency will not be
available if it is not explicitly listed as a dependency.

You could also imagine a future where the Setup.hs script found the test
files and compiled a single executable which would run all the tests,
rather than invoking runghc on each one individually.

Fixes haskell#8356

* hurd: Enable using $ORIGIN in RPATH

GNU/Hurd fully supports RPATH and the $ORIGIN development, and we indeed
want to use it for relocatable installations shipped in Debian GNU/Hurd.

* Fix the platform string for GNU/Hurd

Since version 9.4.7-1, ghc fails to build on the GNU/Hurd port of Debian,
see

https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=hurd-i386&ver=9.4.7-1&stamp=1697717885&raw=0

Error, rule finished running but did not produce file:
  _build/stage0/lib/i386-gnu-ghc-9.4.6/ghc-boot-th-9.4.7/libHSghc-boot-th-9.4.7.a

and indeed, what did get produce was rather
_build/stage0/lib/i386-hurd-ghc-9.4.6/ghc-boot-th-9.4.7/libHSghc-boot-th-9.4.7.a
(i386-hurd instead of i386-gnu).

This is due to confusion between hurd and gnu in various places.  Apparently
previous versions of ghc were using gnu for the GNU/Hurd port, and thus
putting libraries etc. in i386-gnu. So we have to follow the existing
practice.

* Fix configuation of ldProgram

Standard GNU `ld` ues `--relocatable` while `ld.gold` uses a `-relocatable`
flag (with a single `-`). Code will now detect both versions.

* Chain configuration of ldProgram

`ldProgram` gets configured in two places, a seemingly default and
a GHC specific version. The later needs to be updated so that it
first calls the default configuration and then the new GHC version.

* Use linker capability detection to improve linker use

The function `comperSupportsGhciLibs` has been renamed to
`linkerSupportsGhciLibs` because its about the linker not the compiler.

The function `comperSupportsGhciLibs` was using the compiler version
as a proxy for whether the linker supports relocatable objects. Now
support for relocatable objects is detected by running the linker.

* add `merge+no rebase`

and a few typos while reviewing

* Add support for 64-bit SPARC as a separate architecture

Previously, sparc64 was defined as an alias for the 32-bit SPARC
architecture which was true while SPARC mainland was mostly 32
bits. More recently, 64-bit SPARC has become a port of its own,
so it needs to be treated as a separate architecture.

* Remove debug-conflict-sets flag from solver package

Fixes haskell#8937.

The debug-conflict-sets build flag probably hasn't been used for a long time,
and it isn't currently tested. This commit removes the flag, converts the
ConflictSet type back to a newtype, and removes an unnecessary instance.

* Finish improvements to the CI configuration for documentation changes (haskell#9460)

* Add bootstrap postjob to CI config

Add a new job to the bootstrap.yml GitHub action config.
This job succeeds if, and only if, all the other bootstrap
jobs succeed.

* Do not run bootstrap CI jobs for documentation changes

The approach was already introduced in haskell#9355 for the validate jobs.
This commit introduces the same change also for the bootstrap jobs.

* Also ignore CONTRIBUTING.md and README.md in CI

We do not run the entire CI suite for documentation changes.
Previously, only changes which were restricted to the 'docs/'
subdirectory were considered to be documentation changes.
With this commit we also recognize changes to README.md and
CONTRIBUTING.md as documentation changes.

* Document improved CI for documentation in CONTRIBUTING.md

The CONTRIBUTING.md file now mentions that documentation changes
do not waste expensive CI resources.

* Recognize all README.md in subdirs as documentation

Expensive CI jobs should not run on changes which affect only
README.md files.

* formatting: Add style-commit makefile target

This target allows you to format a range of commits, for example:

```
make style-commit COMMIT=HEAD~1
> Last commit is formatted
make style-commit COMMIT=abcde
> Commits between HEAD and abcde are formatted
```

* Fix assertion failure when combining build-tool-depends and --enable-documentation

The `setDocumentation` function was modifying the elaborated package
after the hash was computed. This led to the assertion failing as the
computed hash was different to what was computed in the initial install
plan.

Therefore in order to fix this we either needed to:

1. Set elabBuildHaddocks = False at the point where the hash is
   initially computed.
2. Verify that elabBuildHaddocks = True will not lead to unexpected
   results.

The latter has been implemented.

The elabBuildHaddocks option is only consulted in
`hasValidHaddockTargets`, at which point documentation building the
executable component is disabled because elabHaddockExecutables is
False.

In the added test we ensure this by checking that we didn't build
documentation for the executable which is built because of
build-tool-depends.

Fixes haskell#6006 haskell#8313

* testsuite: Improve error message in findDependencyInStore

* Only move code to Simple/GHC/Build*

* CPP mingw32_HOST_OS for more imports

* cabal-install-solver: fix pkgconf 1.9 --modversion regression

Check that the numbers of *versions* output is equal to the number of pkgconf's

fixes haskell#8923

The pkgconf behavior was reverted upstream in 2.0

(this should cover the case too of checking that equal pkgList lines are output also)

* External commands: Add tests for haskell#9402 haskell#9403 haskell#9404

This adds 4 tests which test the new external commands feature:

* ExternalCommand - Tests the expected usage of external command invoked
  via cabal-install
* ExternalCommandSetup - Tests that the ./Setup interface does not
  support external commands (haskell#9403)
* ExternalCommandEnv - Tests that environment variables are set and
  preserved appropiately  (haskell#9402)
* ExternalCommandHelp - Test that `cabal help <cmd>` is interpreted appropiately (haskell#9404)

* Finish off the external commands feature

* Remove 'CommandDelegate' in favour of abstracting the fallback in
  'commandsRun', there is a new variant 'commdandRunWithFallback' which
  takes a continuation
  - This restores the modularity between the `Cabal` library and
    `cabal-install` as now `Cabal` doesn't need to know anything about
    the external command interface.
  - Fixes haskell#9403
* Set the $CABAL environment variable to the current executable path
  - This allows external commands to be implemented by calling $CABAL,
    which is strongly preferred to linking against the Cabal library as
    there is no easy way to guantee your tool and `cabal-install` link
    against the same `Cabal` library.
  - Fixes haskell#9402
* Pass the name of the argument
  - This allows external commands to be implemented as symlinks to an
    executable, and multiple commands can be interpreted by the same
    executable.
  - Fixes haskell#9405
* `cabal help <cmd>` is interpreted as `cabal-<cmd> --help` for external
  commands.
  - This allows the `help` command to also work for external
  commands and hence they are better integrated into cabal-install.
  - Fixes haskell#9404

The tests are updated to test all these additions.

These features bring the external command interface up to par with the
cargo external command interface.

* Use Base16 hash for script path.

Issue haskell#9334 shows that `%` characters on Windows result in invalid
paths, also `/` characters on Linux create invalid paths.

This changes from using base64 to using base16 with the same length
we use for unit-ids.

* Migrate to haskell-actions/setup

As of 2023-09-09, haskell/action/setup is no longer maintained.

The comment

  # latest is mandatory for cabal-testsuite, see haskell#8133

is removed; as the validate job was already fixing a version of cabal-install.

* testsuite: Introduce Cabal-tests library for common testsuite functions

I noticed that Distribution.Utils.TempTestDir was only used in the
testsuite but defined in the Cabal library. Rather than expose this in
the public interface of the `Cabal` library, it is cleaner to refactor
it into a separate library (`Cabal-tests`) which can be used by any
testsuite component.

Also, in future it gives a clearer place to put utility functions which
need to be shared across the testsuite but not exposed in Cabal.
Cabal-tests can also freely add dependencies (such as exceptions) which
we might want to avoid adding to the Cabal library.

Fixes haskell#9453

* GHC 9.8 compat: pacify -Wx-partial

* GHC 9.8 compat: update hashes of data structures as computed by Structured

It seems, GHC 9.8 changed something in the code generation for data types.
Structured class is supposed to catch such cases.

* GHC 9.8 compat: bump base, update Unknown GHC

And bump Cabal's "supported version" of GHC

* CI: GHC 9.8

* merge master

* Hackage should be capitalized

---------

Co-authored-by: Artem Pelenitsyn <a.pelenitsyn@gmail.com>
Co-authored-by: Bryan Richter <bryan@haskell.foundation>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Co-authored-by: Phil de Joux <philderbeast@gmail.com>
Co-authored-by: Yvan Sraka <yvan@sraka.xyz>
Co-authored-by: Andreas Abel <andreas.abel@ifi.lmu.de>
Co-authored-by: Jens Petersen <petersen@redhat.com>
Co-authored-by: Andrea Bedini <andrea.bedini@tweag.io>
Co-authored-by: Hamish Mackenzie <Hamish.K.Mackenzie@gmail.com>
Co-authored-by: Malte Neuss <malteneuss@users.noreply.github.com>
Co-authored-by: Bodigrim <andrew.lelechenko@gmail.com>
Co-authored-by: David Binder <david.binder@uni-tuebingen.de>
Co-authored-by: David Binder <binderd@informatik.uni-tuebingen.de>
Co-authored-by: Javier Sagredo <jasataco@gmail.com>
Co-authored-by: Andrea Bedini <andrea@andreabedini.com>
Co-authored-by: Matthew Pickering <matthewtpickering@gmail.com>
Co-authored-by: Fendor <power.walross@gmail.com>
Co-authored-by: Hécate Moonlight <Kleidukos@users.noreply.github.com>
Co-authored-by: Andreas Klebinger <klebinger.andreas@gmx.at>
Co-authored-by: Francesco Ariis <fa-ml@ariis.it>
Co-authored-by: Troels Henriksen <athas@sigkill.dk>
Co-authored-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Co-authored-by: Erik de Castro Lopo <erikd@mega-nerd.com>
Co-authored-by: brandon s allbery kf8nh <allbery.b@gmail.com>
Co-authored-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Co-authored-by: Kristen Kozak <grayjay@wordroute.com>
Co-authored-by: Javier Sagredo <javier.sagredo@iohk.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: RFC Requests for Comment
Projects
None yet
Development

No branches or pull requests

6 participants