| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would pick up Stack's Cabal version with ghc-pkg on the
global package-db. This however ignores that Stack also supports custom
Setup.hs with the Cabal version from the snapshot instead.
In cabal v2-build we have a similar problem. We used to assume that
plan.json's cabal-lib-version is used uniformly across units but this is
similarly untrue.
To fix both of these we re-stage the cabal version query to after
reconfiguring a unit, then we can just lookup the Cabal version in
setup-config.
Fixes #95
|
|
|
|
|
|
| |
Cabal includes the Setup.hs executable as a component in plan.json, however
there isn't a target to build it directly so we just ignore it for not when
reading unit info.
|
| |
|
|
|
|
|
|
|
| |
Stackage can get into the situation where they have a different Cabal
version from what was shipped with GHC. This is usually not a problem but
when stack installs any package with build-type:custom this pulls in the
Stackage Cabal version!
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently we can get source-repo-packages in plan.json even when filtering
for `"style": "local"`(`UnitTypeLocal`). It's possible the root cause here
is a cabal bug as source-repository-package should really be treated more
like a tarball than a local package. Regardless we simply filter units by
actually checking for `uPkgSrc=Just LocalUnpackedPackage` instead of
relying on "style".
This fixes #99
|
|
|
|
| |
See #89
|
|
|
|
|
|
| |
Cabal still doesn't really know about these depencies and will only start
GHC if it needs to rebuild for other reasons. However! Since all the files
we pull in are source files for the library anyways it all works out.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Cabal's versionDigitParser limits the version nuber to nine digits, this
used to not be checked for and used to just overflow the resulting Word.
See 7d4eee68fcb3 ("Limit version number parts to be 9 digits")
|
|
|
|
| |
This reverts commit 04c2d34f1874bc198288d33c784bc26f89280ee2.
|
|
|
|
| |
Cabal's GHC.configure doesn't demand haddock exist, so we have to handle the case where it's not installed.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Private libraries have a bunch of bugs in cabal currently:
* https://github.com/haskell/cabal/issues/6211
* https://github.com/haskell/cabal/issues/6483
and devs of haskell-ide-engine are encountering this bug frequently.
To mitigate this issue, remove usage of private libraries and use
a common stanza to have the same re-use as before.
This change can be undone when the mentioned issues have been resolved.
|
| |
|
| |
|
|
|
|
|
|
| |
Previously we would pick up Stack's Cabal version with ghc-pkg on the
global package-db. This however ignores that Stack also supports custom
Setup.hs with the Cabal version from the snapshot instead.
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we are invoked under Stack (as part of HIE's test suite for example)
our choice of Cabal library when invoking GHC gets interferred with by the
GHC_ENVIRONMENT variable.
Since we're just using boot packages simply unsetting GHC package related
envvars seems like a fairly decent fix here. See the issue below for more
details.
Fixes #78
|
| |
|
|
|
|
|
|
| |
Using ghc-paths bypasses cabal's rebuild checks though, for example,
installing the compiler into a different directory will change the libdir
but cabal won't recompile ghc-paths.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This fixes scenarios such as:
cabal: Ambiguous target 'test:foo'. It could be:
A:test:foo (component)
B:test:foo (component)
|
|
|
|
|
|
| |
Stack and Cabal are likely to have different orderings here. This has
caused a difference in behaviour depending on the build-tool used
downstream in HIE so for sanity's sake just sort the list.
|
| |
|
|
|
|
|
|
|
|
| |
All contributors have agreed on public record at
https://github.com/DanielG/cabal-helper/issues/76
Fixes #76
|
|
|
|
|
|
|
|
| |
We want to be able to have the build tool use exactly the compiler and
related executables we choose. Stack doesn't really like that mode of
operation and insists on getting everything from PATH itself so this commit
adds support for creating a temporary symlink farm to convince Stack to use
the executables we want it to use.
|
|
|
|
|
| |
We include the correct stack version in the CI images now and since the
relevant stack version is now released it is easy to install for devs.
|
| |
|
|
|
|
| |
Turns out I'm an idiot and 10eX is actually 10^(x+1).
|