Cabal 3: in build-depends, package name gets treated as internal library name ("legacy" syntax) even when using the pkg:lib qualified syntax

[ekmett]

I had 3 libraries:

fontconfig -- provides fontconfig bindings
fontconfig-freetype -- provides supplementary support for freetype
freetype -- provides freetype bindings

I've consolidated the first two into one using public sublibraries. I had to rename the new sublibrary for fontconfig-freetype to fcfreetype to hack it into place.

Now I'd like to be able to use the unmangled name, so that users would incur a dependency on fontconfig:freetype or fontconfig:{freetype}, and all that really changes is a character or so in their imports, but I'd be able to maintain a single package on hackage. While users who do not want or need freetype can depend on fontconfig:core and bypass the extras.

Done right this sort of thing seems like a path to having many many little fine-grained internal dependencies, so you can incur dependencies on just the functionality you need out of a larger package.

But it seems no matter how I try to refer to the external library freetype, I'm getting a cycle detected as if the top level fontconfig library which re-exports its own sub-library freetypes contents is in a cycle with its member.

I'm guessing either I have no way to refer to the external freetype in the current naming convention, or something is one step too simple in the cycle detector? What is the correct name to use to refer to a library that isn't the one in the current package being built, but rather the name in the top level namespace?

See this associated commit to a side-branch for this issue.

The repository should compile with ghc 8.8 and cabal 3. I apologize for not distilling a smaller issue, but basically any example of library name shadowing should do.

This arises for me at least, because I also have about a dozen more of these, each of which would need distinct name mangling conventions.(e.g. harfbuzz-freetype, harfbuzz-icu) and it seems a shame to make the user use harfbuzz:hb-ft or something rather than remain as clear as the current naming.

[fgaz]

That's the legacy syntax :-/

Internal library names shadow external package names.

I was planning to leave it for another .cabal version or so, but I guess we could just disable it now since conflicts like this are likely to happen

/cc @hvr

[fgaz]

Btw you may want to add visibility:public to those sublibrary stanzas. The Cabal shipped with ghc 8.8 alpha does not enforce it, but from rc1 onwards it will

[hvr]

@fgaz what do you consider "legacy" syntax?

Shouldn't build-depends: foo:bar always unambigously refer to the (sub)lib bar in the package foo?

Likewise, shouldn't build-depends: foo:foo always refer unambigously to the primary library of the package foo?

I.e. by using the fully qualified syntax we should always be able to refer to an absolute target, regardless of what intra-package sublibs happen to be in scope.

Whether build-depends: bar is subject to (consistent!) shadowing by local sublib (i.e. when a local intra-package sublib named bar exists it shall shadow an external package-name bar) shouldn't be a an actual problem -- and I'm hesitant to change these shadowing semantics as we'd still need to keep them for cabal-version:2.4 and older, unless there's a compelling reason to do so that outweights the potentially confusing switch of semantics as a function of the declared cabal-version:

[fgaz]

@hvr is right, I didn't see you used the full qualified syntax (freetype:freetype), which should work. Somehow the package name gets treated as a library name anyway. This is indeed a bug

[phadej]

We cannot fix this in 3.0 anymore

The freetype:freetype (explicit) and freetype (ambiguous) are both parsed as

+                      condTreeConstraints = [Dependency
+                                               (PackageName "freetype")
+                                               AnyVersion
+                                               (Set.fromList [LMainLibName])],

So latter in the pipeline we cannot know which way it was originally. Reschedulling for 3.2

[phadej]

Sorry for the spam. Actually I'm scheduling this for 3.4 directly, as the current plan is to not produce cabal-version: 3.2. We don't have time, and this would be the only change into the format.

[phadej]

Whether build-depends: bar is subject to (consistent!) shadowing by local sublib (i.e. when a local intra-package sublib named bar exists it shall shadow an external package-name bar) shouldn't be a an actual problem -- and I'm hesitant to change these shadowing semantics as we'd still need to keep them for cabal-version:2.4 and older, unless there's a compelling reason to do so that outweights the potentially confusing switch of semantics as a function of the declared cabal-version:

I think this might be a solution, as interpretation of names happens after the parsing. Then bar would be shorthand for bar:bar independently of context. And you'll need to write mylib:bar to point to internal dependencies.

EDIT: getInternalPackages is one function to look at. It does shadowing currently.