Fix some bugs related to detailed-0.9 test suites #3015
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ezyang
force-pushed
the
DuplicateModuleName
branch
6 times, most recently
from
2e77ba5 to
e8e47f6
Compare
ezyang
changed the title
ezyang
force-pushed
the
DuplicateModuleName
branch
from
e8e47f6 to
45331e8
Compare
Instead of qualifying, in some cases I just added an extra
'hiding' pragma to squelch errors. Common conflicts
(just grep for hiding):
- Flag
- Distribution.Simple.Compiler
- Distribution.PackageDescription
- Distribution.Simple.Setup
- installedComponentId
- Distribution.Package
- Distribution.InstalledPackageInfo
- doesFileExist
- Distribution.PackageDescription.Check
- instantiatedWith
- I renamed the field in InstalledPackageInfo. But
it's probably going away with Backpack bits; I
migth just excise it soon.
- absoluteInstallDirs and substPathTemplate
- Distribution.Simple.InstallDirs
- Distribution.Simple.LocalBuildInfo
I fixed some shadowing errors by renaming local variables in some cases.
Common shadowings (we should perhaps consider not using these as
method/field names):
- freeVars
- components
- noVersion
- verbosity
- get
- description
- name
Some data structures were moved around (IPIConvert and ABIHash)
to make it easier to handle import lists.
Some functions in Utils could be turned into reexports of standard
library functions.
No explicit imports were removed from non-Cabal imports. These
imports help maintain warning cleanliness across versions of GHC,
so I don't recommend removing them.
Signed-off-by: Edward Z. Yang <[email protected]>
Signed-off-by: Edward Z. Yang <[email protected]>
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
force-pushed
the
DuplicateModuleName
branch
from
45331e8 to
b4d3e69
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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):
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.