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

Cabal accepts invalid sublibrary names. #10778

Open
phadej opened this issue Feb 4, 2025 · 0 comments
Open

Cabal accepts invalid sublibrary names. #10778

phadej opened this issue Feb 4, 2025 · 0 comments

Comments

@phadej
Copy link
Collaborator

phadej commented Feb 4, 2025

See https://github.com/phadej/cabal-sublib-bug

Describe the bug

Cabal parser accepts

cabal-version: 3.8
name: cabal-sublib-bug
version: 0

library james-bond-007
  default-language: Haskell2010
  hs-source-dirs: src-a
  build-depends: base <5
  exposed-modules: A

library
  default-language: Haskell2010
  hs-source-dirs: src-a
  build-depends: base <5
  exposed-modules: B

  -- note: for private libraries this is not an issue,
  -- as we cannot depend on them, the field below doesn't parse
  -- public libraries couldnt' be used either, but we'll catch that too late!
  -- build-depends: cabal-sublib-bug:james-bond-007

in particular the library james-bond-007.

This doesn't work. We cannot use it build-depends: cabal-sublib-bug:james-bond-007 fails to parse. But if we don't add the dependency it will fail to compile:

Error: [Cabal-7125]
Failed to build cabal-sublib-bug-0.
Failed to build lib:james-bond-007 from cabal-sublib-bug-0. The failure occurred during the final install step. The exception was:
  Error: [Cabal-7038]
Couldn't parse the output of 'setup register --gen-pkg-config':".:1:58: \nunexpected end of input\n\n"

To Reproduce

See https://github.com/phadej/cabal-sublib-bug

Expected behavior

I think .cabal parser should reject the invalid library name early.

Additional context

I think, that the (private) library names were restricted to the same rules as library/package names, as we could use them unqualified (just james-bond-007 - but that looks like package id - there's a version). In latest cabal-versions we can only use qualified names (cabal-sublib-bug:james-bond-007), so maybe it would be possible to relax library names in some future cabal spec version. But I think it's not worth the subtleties.

Now, with public sublibraries, it's possible that someone accidentally creates an unusable public library.
The build failure of failing to register (see above) is confusing.

I found this issue because I was creating (private) test library components, like test-01, test-02 etc and not yet using them, and spent good chunk of time wondering what's wrong.

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