Reserve a package namespace for sub-libraries in GHC 7.8 and prior #3017
Description
In #269, and even the existing support for test suite libraries (detailed-0.9) (and related to #2716), there are situations when Cabal generates multiple libraries for a single package. At the moment, these libraries are only ever installed locally; however, they are installed to the inplace package database and are communicated to GHC.
Now, there is a very big wart in the current handling of detailed-0.9 test suite libraries: we give them a very fake, very not-globally-unique installed package ID for their registration in the database. This seems to work mostly OK, but actually the possibility for namespace collision is rife. For example, the test suite is not allowed to have the same name as the package (otherwise, they would collide: fortunately, there is an ad hoc test for this); if the test suite has the same name as a package which Cabal transitively depends on, and god forbid you also have same package, it will SHADOW that package and break the build:
ezyang@sabre:~/Dev/cabal-prof/Cabal/tests/PackageTests/TestNameCollision/child$ cabal configure --enable-tests
Resolving dependencies...
Configuring child-0.1...
Warning: Packages using 'cabal-version: >= 1.10' must specify the
'default-language' field for each component (e.g. Haskell98 or Haskell2010).
If a component uses different languages in different modules then list the
other ones in the 'other-languages' field.
ezyang@sabre:~/Dev/cabal-prof/Cabal/tests/PackageTests/TestNameCollision/child$ cabal build
Building child-0.1...
Preprocessing library child-0.1...
[1 of 1] Compiling Child ( Child.hs, dist/build/Child.o )
Preprocessing test suite 'parent' for child-0.1...
[1 of 1] Compiling Test ( tests/Test.hs, dist/build/Test.o )
<command line>: cannot satisfy -package-id parent-0.1:
parent-0.1 is shadowed by package parent-0.1-3gsxHRbNxfPaOGowp0Hdrk
(use -v for more information)
The correct thing to do (and the thing that will also support us INSTALLING these sub-libraries to the database, as well), is to give PROPER, unique names to these sub-libraries, so that they won't shadow anything else.
That's all very fine and well... but GHC 7.8 (specifically, the shipped Cabal library shipped with ghc-pkg) doesn't support any -package-name which does not parse as a good old-fashioned package ID. So if we want to pick a unique name, we will have to come up with a new package name, which is guaranteed not to conflict with anything on Hackage.
The only way to do this is to reserve a namespace of package names, which we can then use for test names (and whatever private packages we might be interested in.)
I don't particularly care about what we name the prefix, but I propose z- for this purpose: it's short, is an oblique reference to GHC's z-encoding, and has no conflicts on public Hackage. My intention is to then encode "test suite foo in package mylibrary-0.2" as z-mylibrary-z-test-foo-0.2 (with a literal -z- component getting encoded with an extra z).
This hoohah is not necessary for GHC 7.10 or later.