| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
This mainly renames the program version getters to get* and make them
consistenly return Version directly. Such that wrappers like GhcVersion
have to be added at the callsites of the relevant functions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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!
|
| |
|
|
|
| |
We cannot always assume `takeDirectory cfg_file` will be the project source
directory!
|
| |
|
|
| |
This allows discriminating Stack vs. Cabal at the type level more easily.
|
| |
|
|
|
| |
Unfortunately we need this to pass a custom GHC executable path to stack,
since it doesn't have an option to override it on the commandline (yet?).
|
| |
|
|
|
| |
We need to support passing down the path to ghc to new-build/stack in order
to support using a non-default 'ghc' executable.
|
| | |
|
| |
|
|
|
| |
The strings under the "Going to Run These Tests" heading can be plugged
right back into the commandline to run just that test.
|
| | |
|
| |
|
|
|
|
|
| |
This makes it much easier to deal with differences between the build tools
as we can now have functions that only make sense for Cabal and statically
enforce this by passing a 'SCabalProjType pt' as evidence that $pt \in {V1,
V2}$.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
We will need it for the project discovery module later.
|
| | |
|
| |
|
|
| |
[ci skip]
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We cache the produced helper exe without regard to which proj-type produced it,
so this way we avoid building the helper exe (and it's dependencies) with cabal
v1-build which doesn't cache across CI builds.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
We still support <2.0 at runtime this only concerns the Cabal version used at
cabal-install time.
|
| |
|
| |
Move hack to GhcSession test for now, the corresponding logic should be moved into c-h instead of living in ghc-mod instead.
|
| | |
|
