Refactor ProjectBuilding into Package Phases #9524
Conversation
|
Here we are @andreabedini |
alt-romes
force-pushed
the
cabal-9499
branch
from
a0b94d4 to
531e5e2
Compare
|
@alt-romes I'll look at this ASAP <3 |
|
@andreabedini I'm quite happy with how it turned out. FWIW I suggest reviewing locally with --color-moved because not that much changed.
EDIT: The failures are unrelated to the patch since I can reproduce them on master. We're good to go! |
|
@andreabedini the commit message is probably helpful in guiding the review. |
|
@alt-romes: is this ready for review? If so, could you stick the needs-review label on it? |
There was a problem hiding this comment.
@alt-romes: thank you. I think --color-moved doesn't quite work for me now due to the conflicts. But from a quick glimpse, the PR looks good.
|
I've rebased on master and solved the conflict @Mikolaj, it should be good to read now. |
alt-romes
added
merge me
mergify
bot
added
the
merge delay passed
This refactor of Distribution.Client.ProjectBuilding does the following:
* Moves package file monitoring logic to
Distribution.Client.ProjectBuilding.PackageFileMonitor
* Moves the `buildInplaceUnpackedPackage` and
`buildAndInstallUnpackedPackage` with auxiliary functions to
Distribution.Client.ProjectBuilding.UnpackedPackage
* Refactors the common bits of `buildInplaceUnpackedPackage` and
`buildAndInstallUnpackedPackage` to remove considerable code
duplication while simplifying and making both functions more
structured.
Namely, to better structure build inplace vs build and install, I've
introduced:
* `PackageBuildingPhase` describes the various phases of processing the
unpacked package both inplace and on install
* Configure
* Build
* Install (copy + register)
* Test
* Bench
* Repl
* Haddock
* Then, `buildAndRegisterUnpackedPackage` implements the common logic
between the two functions (such as calls to ./Setup and the order of
the phases) but delegates the logic specific to each phase to an
argument function which maps `PackageBuildingPhase` to `IO` actions.
* Now, build inplace and build and install functions are comprised as:
* A wrapper around `buildAndRegisterUnpackedPackage` which does
things specific to each before and after the main phases are
processed
* A delegate function which maps an action to each package
processing phase
Fixes haskell#9499
|
@alt-romes Apologies for the radio silence. Holidays arrived and I missed the boat. This is fanstastic work ⭐ |
|
Thanks @andreabedini! Glad you are content with it. |
This refactor of Distribution.Client.ProjectBuilding does the following:
Moves package file monitoring logic to Distribution.Client.ProjectBuilding.PackageFileMonitor
Moves the
buildInplaceUnpackedPackageandbuildAndInstallUnpackedPackagewith auxiliary functions to Distribution.Client.ProjectBuilding.UnpackedPackageRefactors the common bits of
buildInplaceUnpackedPackageandbuildAndInstallUnpackedPackageto remove considerable code duplication while simplifying and making both functions more structured.Namely, to better structure build inplace vs build and install, I've introduced:
PackageBuildingPhasedescribes the various phases of processing the unpacked package both inplace and on install * Configure * Build * Install (copy + register) * Test * Bench * Repl * HaddockThen,
buildAndRegisterUnpackedPackageimplements the common logic between the two functions (such as calls to ./Setup and the order of the phases) but delegates the logic specific to each phase to an argument function which mapsPackageBuildingPhasetoIOactions.Now, build inplace and build and install functions are comprised as: * A wrapper around
buildAndRegisterUnpackedPackagewhich does things specific to each before and after the main phases are processed * A delegate function which maps an action to each package processing phaseFixes #9499