| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
- removing version constraints in cabal file so that build works with
ghc-9.2.2 + cabal-3.6.2.0
- fixing a do block indentation
- fixing a small poblem with ciSourceDirs because Cabal 3.6.2.0 has
hsSourceDirs :: BuildInfo -> [SymbolicPath PackageDir SourceDir]
instead of
BuildInfo -> [ FilePath ]
|
| |
|
|
|
| |
Also removes the dependency on semigroups since it has been added to base as of 4.9.0.0 and this package dependends on base >= 4.9.1.0.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
It's a bit heavy just for a single use-site for debugging.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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!
|
| |
|
| |
|
|
|
|
|
| |
This allows them to be checked for up-to-date'nes in CI like the
stack-resolvers.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This is mostly an optimization for Nix which already sets up the environment
correctly, so we should reward its users :)
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
base-4.8 came with 7.10 which is the oldest supported GHC now.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Unfortunately we need process-1.2.3.0 for 'readCreateProcess' replacing it for
7.8 is just too much effort.
For testing's sake GHC 7.10 can still build Cabal-1.18.* but not 1.20, seems to
just need a hackage revision though. Just disable 1.20 for now. I don't think
anyone really still uses that.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The use of a wrapper executable to compile the real helper was a design mistake
originally intended to isolate the calling application from a dependency on the
Cabal library completely. This isolation turned out to be rather tedious and
thus was ignored soon, the wrapper remained though.
Due to the way cabal-install installs components of a package into seperate
install trees when using new-install finding the wrapper exe reliably has become
pretty much impossible without huge effort. Hence we remove it and integrate the
functionality into the library instead.
|
| |
|