You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
cabal-version:3.8
name: cabal-sublib-bug
version:0
library james-bond-007default-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"
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.
The text was updated successfully, but these errors were encountered:
See https://github.com/phadej/cabal-sublib-bug
Describe the bug
Cabal parser accepts
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: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 latestcabal-version
s 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.The text was updated successfully, but these errors were encountered: