aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Fix programs-test in windowsjneira2020-05-201-7/+17
|
* Add .exe in win to cabal-helper executablejneira2020-05-201-2/+2
|
* Re-export RelativePath related binders for DistDirStackDaniel Gröber2020-05-171-0/+2
| | | | Fixes #118
* Refactor Program versions handlingDaniel Gröber2020-05-107-37/+39
| | | | | | 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.
* Add suffix V1 to make it explicitjneira2020-05-101-3/+3
|
* Use forward compatible v1 prefix if availablejneira2020-05-101-1/+3
|
* Release version 1.1.0.0Daniel Gröber2020-05-021-1/+1
|
* Fix helper usage messageDaniel Gröber2020-05-021-1/+1
|
* Only pass pjUnits to compile module instead of whole PlanJsonDaniel Gröber2020-05-023-9/+9
|
* Fix Cabal version selection for build-type:CustomDaniel Gröber2020-05-0212-104/+176
| | | | | | | | | | | | | | | | 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
* Ignore setup components from plan.json in readUnitInfoDaniel Gröber2020-05-023-7/+22
| | | | | | Cabal includes the Setup.hs executable as a component in plan.json, however there isn't a target to build it directly so we just ignore it for not when reading unit info.
* Move CabalVersion and related types into a new moduleDaniel Gröber2020-05-029-42/+74
|
* ghc-session: Fix stackBuiltinCabalVersion when snapshot-db has CabalDaniel Gröber2020-05-021-1/+1
| | | | | | | 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!
* Fix cabal projects using source-repository-packageDaniel Gröber2020-05-029-34/+81
| | | | | | | | | | | 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
* Run v2-install in '/' instead of /tmpDaniel Gröber2020-05-011-2/+1
| | | | See #89
* Add call to addDependentFile to track TH dependenciesDaniel Gröber2020-05-011-2/+4
| | | | | | Cabal still doesn't really know about these depencies and will only start GHC if it needs to rebuild for other reasons. However! Since all the files we pull in are source files for the library anyways it all works out.
* Update CI images for GHC 8.10.1 and 8.8.3Daniel Gröber2020-05-012-9/+22
|
* Support GHC 8.10jneira2020-05-014-6/+20
|
* Require Cabal-3.0.1.* on windows for dropExeExtension fixDaniel Gröber2020-04-181-0/+2
|
* Update test dataDaniel Gröber2020-04-182-1/+4
|
* Fix building with Cabal-3.2.0.0Daniel Gröber2020-04-181-1/+1
|
* 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 17:13:44 +0000