Description
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.