Skip to content
Snippets Groups Projects
Matthew Pickering's avatar
Matthew Pickering authored
* In `postProcessInternalDeps` the shadowing logic which existed prior
  to cabal format 3.4 is implemented in a post processing step.

  The algorithm there replaces any references to internal sublibraries
  with an explicit qualifier. For example if you write..

  ```
  library
    build-depends: foo

  library foo
    ...
  ```

  this is reinterpreted as

  ```
  library
    build-depends: mylib:foo

  library foo
    ...
  ```

* In `preProcessInternalDeps` the inverse transformation takes place,
  the goal is to replace `mylib:foo` with just `foo`.

* Things go wrong if you are using version 3.0 for your cabal file
  because
  - In 3.0 the qualifier syntax is introduced so you can be expliciit
    about sublibrary dependencies
  - The shadowing semantics of non-qualified dependencies still exists.

  So the situation is that the user is explicit about the sublibrary

  ```
  library

  library qux
    build-depends: mylib:{mylib, foo}

  library foo
  ```

  1. Post-process leaves this alone, the user is already explicit about
     depending on a sublibrary.
  2. Pre-processing then rewrites `mylib:{mylib, foo}` into two
     dependencies, `mylib` and `foo` (no qualifier).
  3. When parsed these are two separate dependencies rather than treated
     as one dependency, roundtrip test fails.

Solution: Only perform the reverse transformation when the cabal library
version is <= 3.0 and doesn't support the explicit syntax.

Now what happens in these two situations:

1. ```
   library
     build-depends: foo

   library foo
     ...
   ```

  this is reinterpreted as

  ```
  library
    build-depends: mylib:foo

  library foo
    ...
  ```

  then printed and parsed exactly the same way.

2. Explicit syntax is parsed and printed without being munged (when
   supported)

Note: Mixins only supported sublibrary qualifiers from 3.4 whilst
dependencies supported this from 3.0, hence the lack of guard on the
mixins case.

Fixes #10283
4019d172
History
Code owners
Assign users and groups as approvers for specific file changes. Learn more.
Name Last commit Last update
..
src
README.md
cabal-validate.cabal

cabal-validate

cabal-validate is a script that builds and tests Cabal and cabal-install. cabal-validate can be run with validate.sh in the repository root; arguments passed to validate.sh will be forwarded to cabal-validate.

Notable arguments include:

  • -v/--verbose to display build and test output in real-time, instead of only if commands fail.
  • -s/--step to run a specific step (e.g. -s build -s lib-tests will only run the build and lib-tests steps).
  • -p/--pattern to filter tests by a pattern.

Hacking on cabal-validate

Overview of important modules:

  • Main.hs encodes all the commands that are run for each step.
  • Cli.hs parses the CLI arguments and resolves default values from the environment, like determining which steps are run by default or the --jobs argument to pass to test suites.
  • Step.hs lists the available steps.