Refactor LocalBuildInfo interface. #3595
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I appear to have messed up LibV09 in the patch: attempting to close over UnitIds that don't exist. I'll have to investigate tomorrow. |
This was referenced Jul 22, 2016
This is an omnibus patch, with the overall goal of making LocalBuildInfo Great Again. The essential ideas: * New type 'TargetInfo' which bundles together 'ComponentLocalBuildInfo' and 'Component'. Eventually, it will also record file paths / module targets. This data structure is basically what you want; a lot of old Cabal code did lots of gyrations converting from 'ComponentLocalBuildInfo' to 'Component' and vice versa, now it's all centralized. * The "new" API for 'LocalBuildInfo' is in "Distribution.Types.LocalBuildInfo". The general principle is, where we previous dealt in 'ComponentLocalBuildInfo', we now deal in 'TargetInfo'. There are shockingly few functions we need! * I've restored 'componentsConfigs' to its Cabal 1.24 signature for BC. * I killed a number of unused functions from "Distribution.Simple.LocalBuildInfo": 'getLocalComponent', 'maybeGetDefaultLibraryLocalBuildInfo', 'maybeGetComponentLocalBuildInfo', 'checkComponentsCyclic' and 'enabledComponents'. For each I checked on Hackage that they were not used. * 'getComponentLocalBuildInfo', 'withComponentsInBuildOrder' and 'componentsInBuildOrder' are deprecated to encourage people to instead use the 'TargetInfo's to finger which components they want built. * 'ComponentLocalBuildInfo' now stores internally the computed 'componentInternalDeps', so that 'LocalBuildInfo' can simply store a graph of 'ComponentLocalBuildInfo'. * The code in Configure has been streamlined to use our new Graph data type to great success. * The type of 'runTest' changed to take a 'ComponentLocalBuildInfo', bringing it more in line with everything else. * New function 'readTargetInfos' which combines 'readBuildTargets' and 'checkBuildTargets', which is what you really wanted anyway. Signed-off-by: Edward Z. Yang <[email protected]>
Signed-off-by: Edward Z. Yang <[email protected]>
Signed-off-by: Edward Z. Yang <[email protected]>
The big change here is that most of the functions in Distribution.Types.HookedBuildInfo have to take a PackageDescription explicitly. I hate the new type, so I primed these new functions, and added functions which use 'localPkgDescr'. Presently those have WARNINGs attached to them so people don't accidentally use them; once we fix 'HookedBuildInfo' we can change this. Signed-off-by: Edward Z. Yang <[email protected]>
Signed-off-by: Edward Z. Yang <[email protected]>
|
Latest build was squash only. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an omnibus patch, with the overall goal of making
LocalBuildInfo Great Again. The essential ideas:
and 'Component'. Eventually, it will also record file paths / module
targets. This data structure is basically what you want; a lot of
old Cabal code did lots of gyrations converting from
'ComponentLocalBuildInfo' to 'Component' and vice versa, now
it's all centralized.
"Distribution.Types.LocalBuildInfo". The general principle
is, where we previous dealt in 'ComponentLocalBuildInfo',
we now deal in 'TargetInfo'. There are shockingly few
functions we need!
for BC.
'getLocalComponent', 'maybeGetDefaultLibraryLocalBuildInfo',
'maybeGetComponentLocalBuildInfo', 'checkComponentsCyclic' and
'enabledComponents'. For each I checked on Hackage that they were
not used.
'componentsInBuildOrder' are deprecated to encourage people
to instead use the 'TargetInfo's to finger which components
they want built.
'componentInternalDeps', so that 'LocalBuildInfo' can simply store
a graph of 'ComponentLocalBuildInfo'.
data type to great success.
bringing it more in line with everything else.
and 'checkBuildTargets', which is what you really wanted anyway.
Signed-off-by: Edward Z. Yang [email protected]