Directly call in-library functions to build packages#11703
Draft
sheaf wants to merge 1 commit intohaskell:masterfrom
Draft
Directly call in-library functions to build packages#11703sheaf wants to merge 1 commit intohaskell:masterfrom
sheaf wants to merge 1 commit intohaskell:masterfrom
Conversation
13 tasks
sheaf
force-pushed
the
wip/cabal-install-hooks
branch
3 times, most recently
from
0ba5efe to
cff8372
Compare
This commit modifies the SetupWrapper mechanism, adding a new way of
building a package: directly calling Cabal library functions (e.g.
'build', 'configure' etc).
This currently requires a bit of GADT trickery to accomodate the fact
that configure returns a LocalBuildInfo which must then be passed to
subsequent phases, while with the old Setup interface everything returns
IO () and communication is done through the filesystem
(the local build info file).
To handle 'build-type: Hooks', this commit introduces the hooks-exe
package, which contains:
- the hooks-exe library, used to compile a set of SetupHooks into an
external executable,
- the hooks-cli library, which is used by cabal-install to communicate
with an external hooks executable.
This package depends on the new `CommunicationHandle` functionality from
haskell/process#308.
sheaf
force-pushed
the
wip/cabal-install-hooks
branch
from
cff8372 to
0a2b46e
Compare
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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 a rebase of #9871. I had to create a new PR as Matthew is no longer active (and that PR was made from his personal fork).
Template B: This PR does not modify behaviour or interface.
This is a major refactoring in how
cabal-installworks, with a few knock-on internal changes to someCaballibrary functionality.It should not cause any breakage for users (I tested
clc-stackageagainst previous versions of this PR, and it all builds unchanged with this branch).This PR modifies
cabal-installto directly go through theCaballibrary when building packages, instead of theSetupinterface (except of course forbuild-type: Custompackages).In particular, to build a package with
build-type: Hooks,cabal-installwill compile the package'sSetupHooksfile into an external hooks executable using the newhooks-exepackage. All hooked operations are then performed by communicating with this external executable, instead of going through an opaqueSetupexecutable. Thehooks-exepackage provides both functionality for compiling an external hooks executable and for interfacing with it. This makes use of theCommunicationHandleAPI that I added toprocess.The main change is to
SetupWrapper: the oldInternalMethodbecomesLibraryMethod, which builds the package by callingCaballibrary functions. This is used to build all packages unlessbuild-type: Customor there is aCaballibrary version mismatch which requires us to fall back to compilingSetup.hsand running that. TheSelfExecmethod as well asforceExternalSetupMethodare removed: they no longer have any purpose, as builds can now be carried out concurrently thanks to 7b90583 and edb808a.The new
Distribution.Client.InLibrarymodule contains all the necessary framework for taking information thatcabal-installhas and invokingCaballibrary functions to perform the appropriate action (configure,build,test,bench, ...). Most of these are pretty simple; the main difficulty is withconfigureas we need to jump to the part of theCabalconfigure code that continues after figuring out information about the system (e.g. compiler information), to avoid wasting work withCabalrediscovering things thatcabal-installalready knows. This required a bit of refactoring inDistribution.Simple.Configure.TODO:
clc-stackageand update the PR description accordingly.