| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are only 8 commits in cabal-helper not by me or alanz, see:
$ git log --author='Daniel Gröber\|Alan Zimmerman' --invert-grep -p
9142d8a9e6ed18faf17a360521fbbbd25f6a3b47
Alan Zimmerman has agreed to the license change on IRC.
The rest are IMO uncopyrightable. I'm pretty sure version-bounds are "facts"
which are inherently uncopyrightable, i.e. the software builds with this and
that version, that's a fact. Simple build fixes such as ae568d10 and eb178a5b
shouldn't really cross the necessary creative threshold.
|
| |
|
| |
|
| |
|