| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
Trac issues: #13194
Reviewers: austin, hvr, erikd, bgamari, dfeuer, duncan
Subscribers: DemiMarie, dfeuer, thomie
Differential Revision: https://phabricator.haskell.org/D3090
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC and ghc-pkg make some pretty hard assumptions about where they're
running on Windows. They assume that they are always running from
`foo/bin/ghc.exe` and that to find the `lib` folder they can drop
`bin/ghc.exe` from the base path and append `lib`.
This is already false for the testsuite, which when testing thenbindist
has one test which puts the binaries in `inplace/test spaces`.
For some reason before this was either being skipped or mysteriously
passing.
But as of `2017.02.11` our luck ran out.
the testsuite triggers a failure such as those in #13310
Let's soften the assumption and just check that `../lib` exists instead.
80 chars
Test Plan: ./validate
Reviewers: austin, erikd, bgamari
Reviewed By: bgamari
Subscribers: thomie, #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D3158
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There ware some old file names (.lhs, ...) at comments.
* mk/config.mk.in
- compiler/hsSyn/HsExpr.lhs -> HsExpr.hs
* utils/ghc-pkg/Main.hs
- compiler/main/Packages.lhs -> Packages.hs
* utils/genapply/Main.hs
- CgRetConv.lhs -> * REMOVE THIS COMMENT (OLDER FILE THAN GHC6) *
- Constants.lhs -> Constants.hs
- compiler/codeGen/CgCallConv.lhs -> compiler/codeGen/StgCmmLayout.hs
- Apply.hc -> Apply.cmm
- HeapStackCheck.hc -> HeapStackCheck.cmm
Reviewers: mpickering, austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D3077
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a complete fix based off of
ed7af26606b3a605a4511065ca1a43b1c0f3b51d for handling
shadowing and out-of-order -package-db flags simultaneously.
The general strategy is we first put all databases together,
overriding packages as necessary. Once this is done, we successfully
prune out broken packages, including packages which depend on a package
whose ABI differs from the ABI we need.
Our check gracefully degrades in the absence of abi-depends, as
we only check deps which are recorded in abi-depends.
Contains time and Cabal submodule update.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: niteria, austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2846
GHC Trac Issues: #12485
|
|
|
|
| |
Updates a number of submodules.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise we end up looking in the wrong place for dynamic libraries on
Windows. This addresses a regression introduced by D2611. See #12479.
Test Plan: validate across platforms
Reviewers: austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2640
GHC Trac Issues: #12479
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Build systems / package managers want to be able to control the file
layout of installed libraries. In general they may want/need to be able
to put the static libraries and dynamic libraries in different places.
The ghc-pkg library regisrtation needs to be able to handle this.
This is already possible in principle by listing both a static lib dir
and a dynamic lib dir in the library-dirs field (indeed some previous
versions of Cabal did this for shared libs on ELF platforms).
The downside of listing both dirs is twofold. There is a lack of
precision, if we're not careful with naming then we could end up
picking up the wrong library. The more immediate problem however is
that if we list both directories then both directories get included
into the ELF and Mach-O shared object runtime search paths. On ELF this
merely slows down loading of shared libs (affecting prog startup time).
On the latest OSX versions this provokes a much more serious problem:
that there is a rather low limit on the total size of the section
containing the runtime search path (and lib names and related) and thus
listing any unnecessary directories wastes the limited space.
So the solution in this patch is fairly straightforward: split the
static and dynamic library search paths in the ghc-pkg db and its use
within ghc. This is a traditional solution: pkg-config has the same
static / dynamic split (though it describes in in terms of private and
public, but it translates into different behaviour for static and
dynamic linking).
Indeed it would make perfect sense to also have a static/dynamic split
for the list of the libraries to use i.e. to have dynamic variants of
the hs-libraries and extra-libraries fields. These are not immediately
required so this patch does not add it, but it is a reasonable
direction to follow.
To handle compatibility, if the new dynamic-library-dirs field is not
specified then its value is taken from the library-dirs field.
Contains Cabal submodule update.
Test Plan:
Run ./validate
Get christiaanb and carter to test it on OSX Sierra, in combination
with Cabal/cabal-install changes to the default file layout for
libraries.
Reviewers: carter, austin, hvr, christiaanb, bgamari
Reviewed By: christiaanb, bgamari
Subscribers: ezyang, Phyx, thomie
Differential Revision: https://phabricator.haskell.org/D2611
GHC Trac Issues: #12479
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that we don't really need to be able to
extract a ComponentId from UnitId, except in one case.
So compress UnitId into a single FastString.
The one case where we do need the ComponentId is when
we are compiling an instantiated version of a package;
we need the ComponentId to look up the indefinite
version of this package from the database. So now we
just pass it in as an argument -this-component-id.
Also: ghc-pkg now no longer will unregister a package if
you register one with the same package name, if the
instantiations don't match.
Cabal submodule update which tracks the same data type
change.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch implements Backpack for GHC. It's a big patch but I've tried quite
hard to keep things, by-in-large, self-contained.
The user facing specification for Backpack can be found at:
https://github.com/ezyang/ghc-proposals/blob/backpack/proposals/0000-backpack.rst
A guide to the implementation can be found at:
https://github.com/ezyang/ghc-proposals/blob/backpack-impl/proposals/0000-backpack-impl.rst
Has a submodule update for Cabal, as well as a submodule update
for filepath to handle more strict checking of cabal-version.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, austin, simonmar, bgamari, goldfire
Subscribers: thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D1482
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Note that Cabal needs one more bugfix which is in PR to
fix GHC bootstrapping. But the rest of the patch is
ready for review.
Needs a filepath submodule update because cabal check
became more strict.
This patch handles the abstract-ification of Version and
PackageName.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: bgamari, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2555
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2550
GHC Trac Issues: #12637
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's a substantial bump to the haddock.Cabal allocation
stats, because we added 50% more modules, so of course allocations
are going to increase 50%. (But perhaps this is indicative of
some bad constant factor in Haddock related to modules.)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: ggreif, austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2442
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate, try tests in ticket
Reviewers: austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2336
GHC Trac Issues: #12194
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically per-component macros and multiple libraries.
Contains Cabal submodule update.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: austin, bgamari
Reviewed By: austin, bgamari
Subscribers: hvr, thomie
Differential Revision: https://phabricator.haskell.org/D2059
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On the GHC 8.0 RCs, multiple users reported a very strange error
whereby GHC would complain that the symbols names recorded in interface
files did not match the expected name. The reason for this is
that they were using an old version of Cabal which chose symbol
names differently from the installed package ID ('id' field) which
the package was to be installed with; GHC 8.0 now mandates that
these coincides.
This change adds a test to ghc-pkg to make sure that 'id' and 'key'
(which is how Cabal previously reported what the symbol name
was supposed to be) match; if they don't match or key is missing,
we assume that the Cabal was too old.
Bikeshed points:
- Should we offer more information about how to upgrade
Cabal correctly (i.e. specify a version?)
- Should we allow for a missing 'key'? If we allow for
'key' to be missing, we lose the ability to detect
Cabal from GHC 7.8 or earlier being used. If we
require it to be specified, then it will not be possible
for Cabal to deprecate the (unused) field and remove it
without having BC for 8.0.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: austin, bgamari, hvr
Reviewed By: hvr
Subscribers: bergmark, thomie
Differential Revision: https://phabricator.haskell.org/D1892
GHC Trac Issues: #11558
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we had an 'OriginalModule' type in ghc-boot which
was basically identical to 'Module', and we had to do a bit of
gyrating to get it converted into the right form. This commit
introduces a new typeclass, 'DbModuleRep' which represents types
which we know how to serialize to and from the (now renamed) 'DbModule'
type.
The upshot is that we can just store 'Module's DIRECTLY in
the 'InstalledPackageInfo', no conversion needed.
I took the opportunity to clean up ghc-pkg to make its use of
the 'BinaryStringRep' classes more type safe.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1811
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A small cosmetic change, but we have to do a bit of work to
actually support it:
- Cabal submodule update, so that Cabal passes us
-this-unit-id when we ask for it. This includes
a Cabal renaming to be consistent with Unit ID, which
makes ghc-pkg a bit more scrutable.
- Build system is updated to use -this-unit-id rather than
-this-package-key, to avoid deprecation warnings. Needs
a version test so I resurrected the old test we had
(sorry rwbarton!)
- I've *undeprecated* -package-name, so that we are in the same
state as GHC 7.10, since the "correct" flag will have only
entered circulation in GHC 8.0.
- I removed -package-key. Since we didn't deprecate -package-id
I think this should not cause any problems for users; they
can just change their code to use -package-id.
- The package database is indexed by UNIT IDs, not component IDs.
I updated the naming here.
- I dropped the signatures field from ExposedModule; nothing
was using it, and instantiatedWith from the package database
field.
- ghc-pkg was updated to use unit ID nomenclature, I removed
the -package-key flags but I decided not to add any new flags
for now.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: austin, hvr, bgamari
Reviewed By: bgamari
Subscribers: 23Skidoo, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D1780
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Various people (myself included) have complained about the lack of
useful descriptions for the various packages included in GHC's source
tree. Fix this.
Test Plan: Validate
Reviewers: austin, thomie
Reviewed By: thomie
Subscribers: angerman, ezyang
Differential Revision: https://phabricator.haskell.org/D1736
|
|
|
|
|
|
| |
Starting with GHC 7.10 and base-4.8, `Monad` implies `Applicative`,
which allows to simplify some definitions to exploit the superclass
relationship. This a first refactoring to that end.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since GHC 8.1/8.2 only needs to be bootstrap-able by GHC 7.10 and
GHC 8.0 (and GHC 8.2), we can now finally drop all that pre-AMP
compatibility CPP-mess for good!
Reviewers: austin, goldfire, bgamari
Subscribers: goldfire, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D1724
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: jgertm, austin, thomie
Reviewed By: thomie
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1164
GHC Trac Issues: #10785
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The packages in the package database are already sorted alphabetically
by this point (see db_stack_sorted).
This is a better fix for #8245, commit 021b1f8.
Test Plan: look at output of './inplace/bin/ghc-pkg list
[--simple-output]'
Reviewers: austin, bgamari, psibi
Reviewed By: psibi
Differential Revision: https://phabricator.haskell.org/D1579
GHC Trac Issues: #8245
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The behavior is changed to this:
```
ghc-pkg list blahblah
/home/sibi/ghc/inplace/lib/package.conf.d
(no packages)
```
instead of:
```
ghc-pkg list blahblah
/home/sibi/ghc/inplace/lib/package.conf.d
```
Reviewers: austin, thomie, bgamari
Reviewed By: thomie, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1575
GHC Trac Issues: #6119
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1534
|
|
|
|
|
| |
We already used a process-1.4 snapshot with non-bumped version,
so this commit is mostly a `.cabal` file upper-bound relaxation change.
|
|
|
|
|
|
|
|
|
|
| |
This is needed to prepare for #11026 as this update
relaxes the upper bounds on `base` to allow for `base-4.9.0.0`
This also needs to relax a few upper bounds on process in some cabal files
(there will be another process submodule update soon, as a major
version bump of process' version is still pending)
|
| |
|
|
|
|
|
|
| |
Comes with Haddock submodule update.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit contains a Cabal submodule update which unifies installed
package IDs and package keys under a single notion, a Component ID.
We update GHC to keep follow this unification. However, this commit
does NOT rename installed package ID to component ID and package key to
unit ID; the plan is to do that in a companion commit.
- Compiler info now has "Requires unified installed package IDs"
- 'exposed' is now expected to contain unit keys, not IPIDs.
- Shadowing is no more. We now just have a very simple strategy
to deal with duplicate unit keys in combined package databases:
if their ABIs are the same, use the latest one; otherwise error.
Package databases maintain the invariant that there can only
be one entry of a unit ID.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, austin, bgamari, hvr, goldfire
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1184
GHC Trac Issues: #10714
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trac #10796 exposes a way to make `template-haskell`'s `dataToQa` function
freak out if using a `Data` instance that produces a `Constr` (by means of
`toConstr`) using a function name instead of a data constructor name. While
such `Data` instances are somewhat questionable, they are nevertheless present
in popular libraries (e.g., `containers`), so we can at least make `dataToQa`
aware of their existence.
In order to properly distinguish strings which represent variables (as opposed
to data constructors), it was necessary to move functionality from `Lexeme` (in
`ghc`) to `GHC.Lexeme` in a new `ghc-boot` library (which was previously named
`bin-package-db`).
Reviewed By: goldfire, thomie
Differential Revision: https://phabricator.haskell.org/D1313
GHC Trac Issues: #10796
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
See Note [CrossCompiling vs Stage1Only] in mk/config.mk.in.
See Note [Stage1Only vs stage=1] in mk/config.mk.in.
See Note [No stage2 packages when CrossCompiling or Stage1Only].
Also:
* use stage2 to build mkUserGuidePart, as was probably intended.
Now the following represent the same set of packages:
- packages that we build with ghc-stage2
- packages that depend on the ghc library
Those packages are: haddock, mkUserGuidePart and ghctags.
* don't let utils that don't depend on the ghc library depend on its
package-data.mk file. Instead, let those utils directly depend on
the package-data.mk files of the stage1 packages. Not sure if it
improves anything, but I found it easier to explain what's going on
this way.
(partially) reviewed by: austin
Differential Revision: https://phabricator.haskell.org/D1218
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There used to be a lot of custom make code to build ghc-pkg with the
stage0 compiler. Commit ac5a314504554ddef0e855ef9e2fcf51e961f4a6
thankfully cleaned this up, by using the build settings from the
ghc-pkg.cabal file.
This commit removes some remains of the old way of installing ghc-pkg
when Stage1Only=YES. Notably, we called both `build-prog` as
`shell-wrapper`. This is surely wrong, because `build-prog` already
calls `shell-wrapper`. It isn't needed to set WANT_INSTALLED_WRAPPER
either; build-prog does that for us.
This prevents the following warnings when Stage1Only=YES:
utils/ghc-pkg/ghc.mk:46: warning:
overriding commands for target `install_utils/ghc-pkg_dist_wrapper'
utils/ghc-pkg/ghc.mk:37: warning:
ignoring old commands for target `install_utils/ghc-pkg_dist_wrapper'
Also add more comments and restructure a bit.
Reviewed by: austin
Differential Revision: https://phabricator.haskell.org/D1063
|
|
|
|
|
|
|
| |
Lines like the following are filling up the build logs:
binary-0.7.5.0: cannot find any of
["Data/Binary.hi","Data/Binary.p_hi","Data/Binary.dyn_hi"] (ignoring)
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: validate
Reviewers: simonmar, bgamari, austin
Reviewed By: bgamari, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1177
|
|
|
|
|
|
|
|
|
|
| |
This will allow fixing #1851 more easily
("make install-strip" should work).
This reverts 57e2a81c589103b50da80a9e378b1a11285bd521:
"On Cygwin, use a Cygwin-style path for /bin/install's destination"
Update submodule haddock and hsc2hs.
|
|
|
|
| |
Should have been part of 9aa0e4b23d074af44363236fb0f120f07c6e0067.
|
|
|
|
|
| |
Use writeUTF8File and readUTF8File from Distribution.Simple.Utils,
instead of our own buggy copies. Refactoring only.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, we'd install them to something like
xhtml_0ACfOp3hebWD9jGWE4v4G which was fairly ugly; this
commit changes the default install path to contain the full
package name and version, as well as the package key.
Needs a Cabal submodule update for the commit for install paths support
"Add libname install-dirs variable, use it by default. Fixes #2437".
It also contains some miscellaneous fixes for Cabal HEAD.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: austin
Subscribers: bgamari, thomie
Trac Issues: #10479
Differential Revision: https://phabricator.haskell.org/D922
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See Note [writeAtomic leaky abstraction].
GHC on Linux already received a patch for this bug in
e0801a0fb342eea9a312906eab72874d631271cf. On Windows several cabal tests
were hitting the bug, causing validate failures, but we never noticed
because of all the other tests that were failing on Windows. And it
didn't start happening till `getModificationTime` received sub-second
resolution support on Windows in
5cf76186d373842bf64d49cecb09e0a9ddce3203.
Since there are regression tests already, I am not adding another one.
But for good measure, here is a script that shows the bug without
needing to do a full validate run:
DB=/tmp/package.conf.d.test
GHC_PKG=ghc-pkg #utils/ghc-pkg/dist/build/tmp/ghc-pkg
LOCAL_GHC_PKG="${GHC_PKG} --no-user-package-db --global-package-db=${DB}"
while true; do
rm -rf ${DB}
${LOCAL_GHC_PKG} init "${DB}"
${LOCAL_GHC_PKG} list
done
If you see "WARNING: cache is out of date" after a few seconds, the bug
is not fixed.
Reviewed By: austin
Differential Revision: https://phabricator.haskell.org/D990
GHC Trac Issues: #10205
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: austin
Subscribers: bgamari, thomie
Differential Revision: https://phabricator.haskell.org/D946
GHC Trac Issues: #9507
|
|
|
|
| |
[skip ci]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
* Delete dead code in ghc-pkg (not_yet ready since 2004)
* remove --auto-ghc-libs
Commit 78185538b (2011) mentions:
"Deprecate the ghc-pkg --auto-ghci-libs flag
It was never a universal solution. It only worked with the GNU linker.
It has not been used by Cabal for ages. GHCi can now load .a files so it will
not be needed in future."
"Warning: --auto-ghci-libs is deprecated and will be removed in GHC 7.4"
Reviewers: austin
Reviewed By: austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D666
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: No more frustration.
Test Plan: I tested it.
Reviewers: austin
Reviewed By: austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D658
GHC Trac Issues: #9606
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This should smooth the upgrade process for people and help with testing
the 7.10 RCs. Otherwise people need to first install cabal-install-1.22
before they can use 7.10.
The problem is that older cabal still used file-style package dbs for
the inplace package db when building packages. The workaround is that
both ghc and ghc-pkg will notice when cabal tells them to use a file
style db e.g. "dist/package.conf.inplace" and, so long as that db is
empty (ie content is []) then they'll instead us a dir style db with
the same name but ".d" appended, so in this example that would be
"dist/package.conf.inplace.d". We have to use a separate dir rather
than transparently upgrading because old Cabal really assumes the path
is a file, and if it encounters a dir it will fail.
This seems to be enough for older Cabal to work, and may well be enough
for other scripts that create dbs using "echo [] > package.conf".
Test Plan:
validate and check new and old cabal can sucessfully install things,
including packages that have internal deps (ie using the inplace db)
Reviewers: hvr, tibbe, austin
Reviewed By: tibbe, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D628
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Depends on D485
Summary: Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, austin
Subscribers: thomie, carter
Differential Revision: https://phabricator.haskell.org/D487
|
|
|
|
|
|
|
|
|
|
|
|
| |
The library submission was accepted:
http://www.haskell.org/pipermail/libraries/2014-September/023777.html
The T5892ab testcases were changed to use `Data.Tree` instead of `Data.Version`
Reviewed By: ekmett
Differential Revision: https://phabricator.haskell.org/D395
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
To address #2521 ("Trailing colon on GHC_PACKAGE_PATH doesn't work with
ghc-pkg"), we were using a custom version of splitSearchPath (e4f46f5de). This
solution however caused issue #9698 ("GHC_PACKAGE_PATH should be more lenient
for empty paths").
This patch reverts back to System.FilePath.splitSearchPath (fixes #9698) and
adresses (#2521) by testing for a trailing search path separators explicitly
(instead of implicitly using empty search path elements).
Empty paths are now allowed (ignored on Windows, interpreted as current
directory on Posix systems), and trailing path separator still tack on the
user and system package databases.
Also update submodule filepath, which has a version of splitSearchPath which
handles quotes in the same way as our custom version did.
Test Plan:
$ GHC_PACKAGE_PATH=/::/home: ./ghc-pkg list
...
db stack: ["/",".","/home","<userdb>","<systemdb>"]
...
Reviewers: austin
Reviewed By: austin
Subscribers: thomie, carter, simonmar
Differential Revision: https://phabricator.haskell.org/D414
GHC Trac Issues: #2521, #9698
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Instead of recording exposed-modules and reexported-modules as seperate
fields in the installed package database, this commit merges them into
a single field (exposed-modules). The motivation for this change is
in preparation for the inclusion of *signatures* into the installed
package database, which may also be reexported. Merging the representation
means that we can treat reexports uniformly, no matter if they're a normal
module or a signature.
This commit adds a stub for signatures, but that code isn't wired up to
anything yet.
Contains Cabal submodule update to accommodate these changes.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, duncan, austin
Subscribers: thomie, carter, simonmar
Differential Revision: https://phabricator.haskell.org/D421
|