| 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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
It's a bit heavy just for a single use-site for debugging.
|
| |
|
| |
|
|
|
|
| |
See https://github.com/haskell/cabal/issues/6201 for details about the bug
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we only had a cache for the project info and each unit
info. However adding support for passing overridden compiler paths to build
tools introduces a nasty data dependency: to fully configure 'Program's
we (used to) need ProjInfo which needs an already configured 'Programs' in
readProjInfo (ugh).
After at least four failed attempts at untangling this I arrived at this
solution. Simply splitting up the caches into some smaller parts does the
trick and as a side product forced me to add an abstraction for the caching
logic so as to not reapeat myself even more.
Relatedly runQuery is not just a field accessor anymore but actualy does
some IO of itself to manage the cache and make already configured
'Program's available to the rest of the library.
|
|
|
|
| |
Seems to have been missed when it was added.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One caveat: psiConfigure used to --only-configure the entire project. In
theory we shouldn't even need to do that anymore because we reconfigure
just the unit/target we need to before reading unit info.
However cabal has a bug or well they might consider it just inconsistent
behaviour in that instantiated backpack units' targets are not built by the
target mentioned in plan.json so this per-unit reconfigure is currently
broken there.
The workaround is to just build the entire project before running a query
for now.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
After lamenting the fact that we don't have this in the docs I figured it
really ought to be an exposed abstraction.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Inplace component inlining really always was a nasty cludge, now that we
have proper build-system support we can get rid of it.
- GHC options subsets aren't really needed, we can split these up after
parsing the options using the ghc library.
- Dropped GHC 7.10, it seems unsupportable without the inplace component
inlining, possibly a Stack/lib:Cabal bug, but it is quite old so time for
it to go anyway. This is the second thing commit it was holing up too!
|