aboutsummaryrefslogtreecommitdiff
path: root/src/CabalHelper/Compiletime/Types.hs
Commit message (Collapse)AuthorAgeFilesLines
* Fix Cabal version selection for build-type:CustomDaniel Gröber2020-05-021-6/+6
| | | | | | | | | | | | | | | | 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-021-3/+2
| | | | | | 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-021-0/+1
|
* Unset GHC_ENVIRONMENT and GHC_PACKAGE_PATH before invocing GHCDaniel Gröber2020-01-111-2/+3
| | | | | | | | | | | | 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
* Change license to Apache2Daniel Gröber2019-09-291-11/+6
| | | | | | | | 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-291-1/+6
| | | | | | | | 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.
* Update some code docsDaniel Gröber2019-09-171-13/+16
|
* Implement cabal v2 backpack unit workaroundDaniel Gröber2019-09-171-0/+1
| | | | 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.
* Break cycle between 'Package' and 'Unit'Daniel Gröber2019-09-171-3/+5
|
* Add exported interface for running build-toolsDaniel Gröber2019-09-171-6/+12
|
* Refine ProjLoc docsDaniel Gröber2019-09-171-18/+21
|
* Introduce Package abstractonDaniel Gröber2019-09-171-15/+13
| | | | | After lamenting the fact that we don't have this in the docs I figured it really ought to be an exposed abstraction.
* Remove crusty old helper codeDaniel Gröber2019-09-171-3/+0
| | | | | | | | | | | | - 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-171-21/+29
| | | | This allows discriminating Stack vs. Cabal at the type level more easily.
* Allow passing override-env to process functionsDaniel Gröber2019-09-171-5/+12
| | | | | 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-171-15/+4
| | | | | We need to support passing down the path to ghc to new-build/stack in order to support using a non-default 'ghc' executable.
* Fix some warningsDaniel Gröber2019-09-171-1/+0
| | | | | | | | | I'm turning off -Wunused-imports in the modules that have to deal with ancient Cabal versions because maintaining warning cleanlyness really is quite pointless when you have to deal with all sorts of deprecations and stuff moving around. I don't think having too many imports will ever break anything there unless the modules really get deprecated and removed, but we'll notice that ;)
* Update API docs of main typesDaniel Gröber2019-09-171-27/+93
|
* Split SProjType along build-tool lineDaniel Gröber2019-09-171-22/+37
| | | | | | | This makes it much easier to deal with differences between the build tools as we can now have functions that only make sense for Cabal and statically enforce this by passing a 'SCabalProjType pt' as evidence that $pt \in {V1, V2}$.
* Support cabal-file not being in pkgdir with cabal-v1Daniel Gröber2019-09-171-3/+3
|
* Revert compilerVersion being project-scopeDaniel Gröber2019-05-271-2/+4
| | | | | Turns out the Setup header has the compiler version used to build Setup, not the version the project is configured to use.
* Fix QueryEnv not being compatible with ExDaniel Gröber2019-05-051-2/+1
|
* Add ProjLocV1Dir for easier forward portingDaniel Gröber2019-04-011-2/+8
|
* Make compilerVersion accessor project-scope for V1 projectsDaniel Gröber2019-04-011-2/+28
|
* Promote 'Ex' to exported APIDaniel Gröber2019-03-311-1/+29
| | | | We will need it for the project discovery module later.
* docsDaniel Gröber2019-03-291-9/+19
|
* Add demoteSProjTypeDaniel Gröber2019-02-111-0/+5
|
* docsDaniel Gröber2019-02-111-0/+1
| | | | [ci skip]
* Add log-level to verbosity conditionalDaniel Gröber2019-01-301-2/+4
|
* Add support and test coverage for mulit-pkg projectsDaniel Gröber2019-01-261-26/+64
|
* CommentsDaniel Gröber2019-01-221-22/+24
| | | | [ci skip]
* Reintroduce type conventions: s/proj_type/pt/ s/cache/c/Daniel Gröber2019-01-221-7/+7
|
* Add 'uComponentName' queryDaniel Gröber2019-01-221-1/+15
|
* Refactor Compile (for v2-install)Daniel Gröber2019-01-221-0/+1
|
* Implement `compilerVersion`Daniel Gröber2019-01-221-1/+4
|
* Rename helper command: s/compiler-version/compiler-id/Daniel Gröber2019-01-221-1/+1
|
* Formatting changesDaniel Gröber2019-01-221-1/+1
| | | | [ci skip]
* Include package.yaml in Unit modification times for Stack projectsDaniel Gröber2019-01-221-1/+2
|
* Implement behaviour for cabal new-* (#61)Sebastian Wild2019-01-221-3/+14
| | | | | Add list of components to Unit data type to handle v2 based builds per cabal unit.
* Split up Compile.hs into multiple modulesDaniel Gröber2018-10-271-2/+1
|
* Make some more datatype fields strictDaniel Gröber2018-10-271-3/+3
|
* Suport using Stack's built-in GHC to build the helperDaniel Gröber2018-10-271-20/+22
|
* Refactor Unit handlingDaniel Gröber2018-10-271-29/+50
|
* Add package-id unit-queryDaniel Gröber2018-10-271-0/+3
|
* Add stack supportDaniel Gröber2018-10-271-1/+179
|
* Start refactoring to support cabal v2-buildDaniel Gröber2018-10-271-8/+21
|
* Remove wrapper, integrate functionality into the libraryDaniel Gröber2018-08-261-13/+43
| | | | | | | | | | | | 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.
* Change maintainer email addressDaniel Gröber2018-08-131-1/+1
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-21 06:28:56 +0000