aboutsummaryrefslogtreecommitdiff
path: root/src/CabalHelper
Commit message (Collapse)AuthorAgeFilesLines
* fixing cabal-helperHEADmasterYuchen Pei2022-06-081-60/+62
| | | | | | | | | | - 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 ]
* Fix Cabal-3.4 renaming Flags to PackageFlagsDaniel Gröber2021-02-142-4/+19
|
* Add .exe in win to cabal-helper executablejneira2020-05-201-2/+2
|
* Refactor Program versions handlingDaniel Gröber2020-05-104-14/+24
| | | | | | 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
|
* Fix helper usage messageDaniel Gröber2020-05-021-1/+1
|
* Only pass pjUnits to compile module instead of whole PlanJsonDaniel Gröber2020-05-021-4/+5
|
* Fix Cabal version selection for build-type:CustomDaniel Gröber2020-05-023-14/+24
| | | | | | | | | | | | | | | | 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-022-6/+8
| | | | | | 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-026-41/+70
|
* Fix cabal projects using source-repository-packageDaniel Gröber2020-05-021-24/+23
| | | | | | | | | | | 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.
* Support GHC 8.10jneira2020-05-011-3/+11
|
* 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-112-17/+8
| | | | This reverts commit 04c2d34f1874bc198288d33c784bc26f89280ee2.
* Fix patchBuildToolProgs when haddock cannot be foundJavier Neira2020-02-102-8/+13
| | | | Cabal's GHC.configure doesn't demand haddock exist, so we have to handle the case where it's not installed.
* 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-112-8/+17
| | | | | | 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
* ghc-session: Get GHC libdir from --print-libdir commandDaniel Gröber2019-12-291-0/+4
| | | | | | 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 Cabal HEADDaniel Gröber2019-12-292-11/+13
|
* 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)
* Change license to Apache2Daniel Gröber2019-09-2919-203/+108
| | | | | | | | 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-293-1/+114
| | | | | | | | 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.
* Remove Compat.ProgramDb moduleDaniel Gröber2019-09-291-31/+0
|
* 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-171-1/+0
|
* Update some code docsDaniel Gröber2019-09-172-13/+24
|
* Remove pretty-show dependencyDaniel Gröber2019-09-171-2/+1
| | | | It's a bit heavy just for a single use-site for debugging.
* Fix "Installing lib:Cabal" messageDaniel Gröber2019-09-171-1/+1
|
* Implement cabal v2 backpack unit workaroundDaniel Gröber2019-09-172-7/+35
| | | | See https://github.com/haskell/cabal/issues/6201 for details about the bug
* Make caching more fine grainedDaniel Gröber2019-09-171-9/+63
| | | | | | | | | | | | | | | | | 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.
* Add verbose logging support for readProcess callsDaniel Gröber2019-09-171-11/+24
|
* Fix some import warningsDaniel Gröber2019-09-172-2/+0
|
* Break cycle between 'Package' and 'Unit'Daniel Gröber2019-09-173-5/+9
|
* Add exported interface for running build-toolsDaniel Gröber2019-09-174-12/+71
|
* Refine ProjLoc docsDaniel Gröber2019-09-171-18/+21
|
* Introduce Package abstractonDaniel Gröber2019-09-173-61/+90
| | | | | After lamenting the fact that we don't have this in the docs I figured it really ought to be an exposed abstraction.
* Make ChSetupEntrypoint carry the Main module file nameDaniel Gröber2019-09-171-0/+2
|
* Remove crusty old helper codeDaniel Gröber2019-09-174-343/+42
| | | | | | | | | | | | - 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!
* Fix ProjLoc to source directory correspondenceDaniel Gröber2019-09-171-1/+11
| | | | | We cannot always assume `takeDirectory cfg_file` will be the project source directory!
* Refactor ProjType to be more inductiveDaniel Gröber2019-09-172-22/+30
| | | | This allows discriminating Stack vs. Cabal at the type level more easily.
* Allow passing override-env to process functionsDaniel Gröber2019-09-176-27/+43
| | | | | 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?).
* Merge CompPrograms back into ProgramsDaniel Gröber2019-09-174-34/+23
| | | | | We need to support passing down the path to ghc to new-build/stack in order to support using a non-default 'ghc' executable.
* Add TODO about user-ghc-environment supportDaniel Gröber2019-09-171-0/+5
|
* Flesh out project discovery APIDaniel Gröber2019-09-173-31/+14
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-24 03:28:19 +0000