Reserve a package namespace for sub-libraries in GHC 7.8 and prior #3017
Labels
Comments
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 2, 2016
When building a LibV09 test library, Cabal previously dumped it into the same directory as the library proper. This means that if there are any module name conflicts, they'd override each other. Bad! The way to fix this is to build test libraries in different directories. We need to teach Cabal that not all libraries are the main library. This patch is a minimal patch to make this work for GHC; doubtless refactoring can make this generalize to all other backends (and make it hard to get wrong.) This follows the reserved namespace as per haskell#3017. Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 2, 2016
When building a LibV09 test library, Cabal previously dumped it into the same directory as the library proper. This means that if there are any module name conflicts, they'd override each other. Bad! The way to fix this is to build test libraries in different directories. We need to teach Cabal that not all libraries are the main library. This patch is a minimal patch to make this work for GHC; doubtless refactoring can make this generalize to all other backends (and make it hard to get wrong.) This follows the reserved namespace as per haskell#3017. Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 2, 2016
Cabal's LibV09 support has always been a bit skeevy. The general
idea was that a detailed-0.9 test-suite is built as a library
and an Cabal-provided stub executable. In particular, the test suite
library must be installed to the installed package database so that the
executable can be compiled.
Old versions of Cabal did something very skeevy here: they installed
the test library as a "package", with the same package name as
the "test-suite" stanza; furthermore, they built the products
into the same directory as the library proper.
Consequently, a lot of bad things could happen (both of which I've
added tests for):
1. If the name of the test suite and the name of some other
package coincide (and have the same version), they will clobber
each other. In GHC 7.8 and earlier, this just flat out
kills the build, because it will shadow. There's an explicit
test to make sure test suites don't conflict with the package
name, but you can get unlucky.
2. The test suite library is built into the same directory
as the main library, which means that if the test library
implements the same module name as something in the main
library it will clobber the interface file and badness
will ensue.
This patchset fixes both of these issues, by (1) giving internal
test libraries proper names which are guaranteed to be unique
up to Cabal's dependency resolution, and (2) building the test
suite library into a separate directory.
In doing so, it also lays the groundwork for other types of
internal libraries, e.g. haskell#269, as well as extra (invisible)
libraries which we may install.
For GHC 7.8 and earlier, we follow the reserved namespace
convention as per haskell#3017.
Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 2, 2016
Cabal's LibV09 support has always been a bit skeevy. The general
idea was that a detailed-0.9 test-suite is built as a library
and an Cabal-provided stub executable. In particular, the test suite
library must be installed to the installed package database so that the
executable can be compiled.
Old versions of Cabal did something very skeevy here: they installed
the test library as a "package", with the same package name as
the "test-suite" stanza; furthermore, they built the products
into the same directory as the library proper.
Consequently, a lot of bad things could happen (both of which I've
added tests for):
1. If the name of the test suite and the name of some other
package coincide (and have the same version), they will clobber
each other. In GHC 7.8 and earlier, this just flat out
kills the build, because it will shadow. There's an explicit
test to make sure test suites don't conflict with the package
name, but you can get unlucky.
2. The test suite library is built into the same directory
as the main library, which means that if the test library
implements the same module name as something in the main
library it will clobber the interface file and badness
will ensue.
This patchset fixes both of these issues, by (1) giving internal
test libraries proper names which are guaranteed to be unique
up to Cabal's dependency resolution, and (2) building the test
suite library into a separate directory.
In doing so, it also lays the groundwork for other types of
internal libraries, e.g. haskell#269, as well as extra (invisible)
libraries which we may install.
For GHC 7.8 and earlier, we follow the reserved namespace
convention as per haskell#3017.
Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 3, 2016
Cabal's LibV09 support has always been a bit skeevy. The general
idea was that a detailed-0.9 test-suite is built as a library
and an Cabal-provided stub executable. In particular, the test suite
library must be installed to the installed package database so that the
executable can be compiled.
Old versions of Cabal did something very skeevy here: they installed
the test library as a "package", with the same package name as
the "test-suite" stanza; furthermore, they built the products
into the same directory as the library proper.
Consequently, a lot of bad things could happen (both of which I've
added tests for):
1. If the name of the test suite and the name of some other
package coincide (and have the same version), they will clobber
each other. In GHC 7.8 and earlier, this just flat out
kills the build, because it will shadow. There's an explicit
test to make sure test suites don't conflict with the package
name, but you can get unlucky.
2. The test suite library is built into the same directory
as the main library, which means that if the test library
implements the same module name as something in the main
library it will clobber the interface file and badness
will ensue.
This patchset fixes both of these issues, by (1) giving internal
test libraries proper names which are guaranteed to be unique
up to Cabal's dependency resolution, and (2) building the test
suite library into a separate directory.
In doing so, it also lays the groundwork for other types of
internal libraries, e.g. haskell#269, as well as extra (invisible)
libraries which we may install.
For GHC 7.8 and earlier, we follow the reserved namespace
convention as per haskell#3017.
Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
to ezyang/cabal
that referenced
this issue
Jan 8, 2016
Cabal's LibV09 support has always been a bit skeevy. The general
idea was that a detailed-0.9 test-suite is built as a library
and an Cabal-provided stub executable. In particular, the test suite
library must be installed to the installed package database so that the
executable can be compiled.
Old versions of Cabal did something very skeevy here: they installed
the test library as a "package", with the same package name as
the "test-suite" stanza; furthermore, they built the products
into the same directory as the library proper.
Consequently, a lot of bad things could happen (both of which I've
added tests for):
1. If the name of the test suite and the name of some other
package coincide (and have the same version), they will clobber
each other. In GHC 7.8 and earlier, this just flat out
kills the build, because it will shadow. There's an explicit
test to make sure test suites don't conflict with the package
name, but you can get unlucky.
2. The test suite library is built into the same directory
as the main library, which means that if the test library
implements the same module name as something in the main
library it will clobber the interface file and badness
will ensue.
This patchset fixes both of these issues, by (1) giving internal
test libraries proper names which are guaranteed to be unique
up to Cabal's dependency resolution, and (2) building the test
suite library into a separate directory.
In doing so, it also lays the groundwork for other types of
internal libraries, e.g. haskell#269, as well as extra (invisible)
libraries which we may install.
For GHC 7.8 and earlier, we follow the reserved namespace
convention as per haskell#3017.
Signed-off-by: Edward Z. Yang <[email protected]>
ezyang
added a commit
that referenced
this issue
Jan 10, 2016
Cabal's LibV09 support has always been a bit skeevy. The general
idea was that a detailed-0.9 test-suite is built as a library
and an Cabal-provided stub executable. In particular, the test suite
library must be installed to the installed package database so that the
executable can be compiled.
Old versions of Cabal did something very skeevy here: they installed
the test library as a "package", with the same package name as
the "test-suite" stanza; furthermore, they built the products
into the same directory as the library proper.
Consequently, a lot of bad things could happen (both of which I've
added tests for):
1. If the name of the test suite and the name of some other
package coincide (and have the same version), they will clobber
each other. In GHC 7.8 and earlier, this just flat out
kills the build, because it will shadow. There's an explicit
test to make sure test suites don't conflict with the package
name, but you can get unlucky.
2. The test suite library is built into the same directory
as the main library, which means that if the test library
implements the same module name as something in the main
library it will clobber the interface file and badness
will ensue.
This patchset fixes both of these issues, by (1) giving internal
test libraries proper names which are guaranteed to be unique
up to Cabal's dependency resolution, and (2) building the test
suite library into a separate directory.
In doing so, it also lays the groundwork for other types of
internal libraries, e.g. #269, as well as extra (invisible)
libraries which we may install.
For GHC 7.8 and earlier, we follow the reserved namespace
convention as per #3017.
Signed-off-by: Edward Z. Yang <[email protected]>
Closed
garetxe
pushed a commit
to garetxe/cabal
that referenced
this issue
Mar 5, 2016
Cabal's LibV09 support has always been a bit skeevy. The general
idea was that a detailed-0.9 test-suite is built as a library
and an Cabal-provided stub executable. In particular, the test suite
library must be installed to the installed package database so that the
executable can be compiled.
Old versions of Cabal did something very skeevy here: they installed
the test library as a "package", with the same package name as
the "test-suite" stanza; furthermore, they built the products
into the same directory as the library proper.
Consequently, a lot of bad things could happen (both of which I've
added tests for):
1. If the name of the test suite and the name of some other
package coincide (and have the same version), they will clobber
each other. In GHC 7.8 and earlier, this just flat out
kills the build, because it will shadow. There's an explicit
test to make sure test suites don't conflict with the package
name, but you can get unlucky.
2. The test suite library is built into the same directory
as the main library, which means that if the test library
implements the same module name as something in the main
library it will clobber the interface file and badness
will ensue.
This patchset fixes both of these issues, by (1) giving internal
test libraries proper names which are guaranteed to be unique
up to Cabal's dependency resolution, and (2) building the test
suite library into a separate directory.
In doing so, it also lays the groundwork for other types of
internal libraries, e.g. haskell#269, as well as extra (invisible)
libraries which we may install.
For GHC 7.8 and earlier, we follow the reserved namespace
convention as per haskell#3017.
Signed-off-by: Edward Z. Yang <[email protected]>
|
OK it's been reserved in HEAD. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
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-namewhich 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" asz-mylibrary-z-test-foo-0.2(with a literal-z-component getting encoded with an extraz).This hoohah is not necessary for GHC 7.10 or later.
The text was updated successfully, but these errors were encountered: