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

--haddock-executables index does not distinguish Main modules #6514

Open
mpilgrem opened this issue Mar 9, 2024 · 2 comments
Open

--haddock-executables index does not distinguish Main modules #6514

mpilgrem opened this issue Mar 9, 2024 · 2 comments

Comments

@mpilgrem
Copy link
Member

mpilgrem commented Mar 9, 2024

Version 2.16.0, Git revision 1817292 (10654 commits) PRE-RELEASE x86_64 has --haddock-executables (built on top of Cabal (the library)'s haddock --executables), but there are problems with the index.

Consider a two-package project (packageA, packageB) each with two executable components (eg packageA-exe1, packageA-exe2). The index generated for project packages has four links to Main but all of them are to the Main of packageB-exe1.

Using haddock --show-interface reveals that all four *.haddock files commence:

{"link_env":{"$main$Main$main":"Main", ...

That can be contrasted with the two *.haddock files for the main library:

{"link_env":{"$packageA-0.1.0.0-ErEp6QMCDA5L7wclG18d4W$Lib$someFunc":"Lib"}, ...

and

{"link_env":{"$packageB-0.1.0.0-LJmkqLQIxknEQ7YIpA65Ah$Lib$someFunc":"Lib"}, ...

--cabal-verbosity 3 reveals that, with the main library, Cabal (the library) invokes Haddock with options that include:

packageA> --optghc=-this-unit-id
packageA> --optghc=packageA-0.1.0.0-ErEp6QMCDA5L7wclG18d4W

packageB> --optghc=-this-unit-id
packageB> --optghc=packageB-0.1.0.0-LJmkqLQIxknEQ7YIpA65Ah

There is no equivalent for when Cabal invokes Haddock for the executable components.

@mpilgrem
Copy link
Member Author

mpilgrem commented Mar 9, 2024

@Mikolaj has suggested as reading: https://github.com/haskell/cabal/pulls?q=is%3Apr+author%3Acoot authored by @coot.

@mpilgrem
Copy link
Member Author

mpilgrem commented Mar 9, 2024

If I am correct about the -this-unit-id difference, it has it origins in Distribution.Simple.Haddock.componentGhcOptions and Distribution.Simple.GHC.Internal.componentGhcOptions.

The master branch of Cabal has (extract):

componentGhcOptions verbosity lbi bi clbi odir =
  let implInfo = getImplInfo $ compiler lbi
   in mempty
        { -- Respect -v0, but don't crank up verbosity on GHC if
          -- Cabal verbosity is requested. For that, use --ghc-option=-v instead!
          ghcOptVerbosity = toFlag (min verbosity normal)
        , ghcOptCabal = toFlag True
        , ghcOptThisUnitId = case clbi of
            LibComponentLocalBuildInfo{componentCompatPackageKey = pk} ->
              toFlag pk
            _ | not (unitIdForExes implInfo) -> mempty
            ExeComponentLocalBuildInfo{componentUnitId = uid} ->
              toFlag (unUnitId uid)
            ...

but unitIdForExes is not in any released version (up to Cabal-3.10.2.1 - GHC 9.8.2 comes with Cabal-3.10.2.0.). It was added in haskell/cabal@8d402c7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant