aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Fix datestamp Cabal HEAD version being too longDaniel Gröber2020-04-181-14/+3
| | | | | | | 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")
* Revert "Fix Cabal version selection for Stack (esp. build-type:Custom)"Daniel Gröber2020-02-114-53/+66
| | | | This reverts commit 04c2d34f1874bc198288d33c784bc26f89280ee2.
* Fix patchBuildToolProgs when haddock cannot be foundJavier Neira2020-02-103-14/+19
| | | | Cabal's GHC.configure doesn't demand haddock exist, so we have to handle the case where it's not installed.
* Turn private library into common stanzaunknown2020-02-081-15/+20
| | | | | | | | | | | | 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.
* ci: Allow check-upd job to failDaniel Gröber2020-02-081-0/+3
|
* Fix invokeGhc when using relative pathsDaniel Gröber2020-01-111-4/+8
|
* Fix Cabal version selection for Stack (esp. build-type:Custom)Daniel Gröber2020-01-114-66/+53
| | | | | | 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.
* Unset GHC_ENVIRONMENT and GHC_PACKAGE_PATH before invocing GHCDaniel Gröber2020-01-113-19/+20
| | | | | | | | | | | | 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
* Update stack-resolversDaniel Gröber2020-01-111-1/+1
|
* ghc-session: Get GHC libdir from --print-libdir commandDaniel Gröber2019-12-293-7/+11
| | | | | | 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.
* Fix unused argument warningDaniel Gröber2019-12-291-4/+4
|
* compile-test: Add program commandline optionsDaniel Gröber2019-12-294-28/+42
|
* Fix Cabal HEADDaniel Gröber2019-12-293-12/+14
|
* Add GHC 8.8 supportDaniel Gröber2019-12-293-4/+10
|
* ci: Switch to unified CI imageDaniel Gröber2019-12-282-5/+115
|
* Update stack-resolversDaniel Gröber2019-12-281-1/+1
|
* scripts: Add sdist to bump.shDaniel Gröber2019-12-281-1/+3
|
* Release version 1.0.0.0Daniel Gröber2019-12-270-0/+0
|
* Fix check-testdata.sh exit code propagationDaniel Gröber2019-12-271-4/+15
|
* Update stack-resolversDaniel Gröber2019-12-271-1/+1
|
* Fix README typosDaniel Gröber2019-12-261-3/+3
|
* Fix GitLab pipeline badge URLDaniel Gröber2019-12-261-1/+1
|
* Tweak README and cabal descriptionDaniel Gröber2019-12-262-56/+49
|
* Always include cabal-v2 project in discoverLuke Lau2019-12-211-2/+2
|
* Restore lost [Note Stack Cabal Version]Daniel Gröber2019-12-211-0/+14
|
* Explicitly state package in componentLuke Lau2019-11-271-2/+2
| | | | | | | This fixes scenarios such as: cabal: Ambiguous target 'test:foo'. It could be: A:test:foo (component) B:test:foo (component)
* Store piPackages in sorted orderDaniel Gröber2019-11-031-2/+2
| | | | | | 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.
* Relax lower bound of Win32 down to ghc-8.2.2 versionjneira2019-10-151-1/+1
|
* Change license to Apache2Daniel Gröber2019-09-2923-900/+323
| | | | | | | | All contributors have agreed on public record at https://github.com/DanielG/cabal-helper/issues/76 Fixes #76
* Add support for symlink farming as a workaround for StackDaniel Gröber2019-09-298-61/+222
| | | | | | | | 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.
* ghc-session: Remove "stack not installed by CI scripts" errorDaniel Gröber2019-09-291-7/+1
| | | | | 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.
* Remove Compat.ProgramDb moduleDaniel Gröber2019-09-293-34/+7
|
* Fix division factor for helper compilation timerDaniel Gröber2019-09-171-1/+1
| | | | Turns out I'm an idiot and 10eX is actually 10^(x+1).
* Remove redundant timing code for compileHelperDaniel Gröber2019-09-171-6/+0
|
* Use plStackProjectDir instead of 'takeDirectory stack_yaml'Daniel Gröber2019-09-171-4/+4
|
* Fix some warningsDaniel Gröber2019-09-173-4/+1
|
* Update some code docsDaniel Gröber2019-09-173-16/+26
|
* Remove pretty-show dependencyDaniel Gröber2019-09-172-3/+2
| | | | It's a bit heavy just for a single use-site for debugging.
* ghc-session: Fix verbosity functionsDaniel Gröber2019-09-171-2/+2
|
* Fix "Installing lib:Cabal" messageDaniel Gröber2019-09-171-1/+1
|
* Implement cabal v2 backpack unit workaroundDaniel Gröber2019-09-174-11/+42
| | | | See https://github.com/haskell/cabal/issues/6201 for details about the bug
* ci: Update version listsDaniel Gröber2019-09-173-2/+6
|
* Fix check-testdata scriptDaniel Gröber2019-09-172-3/+6
|
* Make caching more fine grainedDaniel Gröber2019-09-173-112/+255
| | | | | | | | | | | | | | | | | 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.
* Export qeCallProcessDaniel Gröber2019-09-171-0/+1
| | | | Seems to have been missed when it was added.
* Add verbose logging support for readProcess callsDaniel Gröber2019-09-172-21/+27
|
* ghc-session: Use new project building APIDaniel Gröber2019-09-171-19/+4
| | | | | | | | | | | | | | 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.
* Fix some import warningsDaniel Gröber2019-09-172-2/+0
|
* Break cycle between 'Package' and 'Unit'Daniel Gröber2019-09-174-6/+10
|
* Add exported interface for running build-toolsDaniel Gröber2019-09-176-71/+164
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 19:32:58 +0000