Plan for better supporting multi-component repls #8491
Labels
attention: needs-help
Help wanted with this issue/PR
attention: pr-welcome
Cabal: cmd/repl
type: discussion
Comments
|
What is a multi-component session? Could you link to some docs? What else uses it, except HLS? Are there any simplified examples of its use around? We are very slowly (as in, in future decades) moving towards deprecating custom setups, so would it be possible to place the NO_DEPS_REQUIRED flags somewhere else? From a cabal dev's perspective, it's a worthy goal to understand and document why deps need to be built before setup-configure and generalize the cabal machinery by relaxing that requirement. This may be a good place to start and we'd welcome docs and refactorings it could bring. Independently, let's discuss the requirements for "multi-component repls" and how to best satisfy them. |
|
Hi! I'm currently writing a blog post on a workaround for the absence of this feature so I have lots of context on this. The core cabal-relevant issue here is that cabal only deals with one target at a time, the so-called "home unit", following the former limitations of GHC. For instance, You cannot GHC now supports the real fix for the multiple home units issue upstream, for which Well-Typed has written a nice blog post. There is also the original GSoC retrospective post from Fendor which provides more context. The current situation, as I understand it, is that GHC supports multiple home units, but cabal does not do the invocations or data model necessary to support it. In the GSoC retrospective linked above, the author mentions having seriously hacked up cabal, breaking the boundary between cabal-install and Cabal, in order to test this, due to some incompatibilities between the data model of cabal and having multiple home units. That patch is obviously not mergeable, and the cabal model would have to be adjusted more carefully/correctly. Thus my understanding of the scope of the work on this problem is to improve the data model for cabal to understand multiple home units and invoke GHC accordingly. Another piece of outside context I can offer is that people have been working on making Bazel work for Haskell, to some extent since the combination of Cabal/GHC don't yet know how to do cross-package build parallelism yet (for instance, say that package A depends on package B, but not all of A depends on B, so the modules of A that don't need B build in parallel): https://www.tweag.io/blog/2022-06-23-haskell-module/ This issue is relevant to this (possibly a duplicate even!): #8238 I understand that @wz1000 is working on parts of this currently. |
|
@dcoutts pointed out that if a Setup.hs depends on a certain package being built already then this can be expressed by adding that package to the @lf- summarises the situation quite well :) Thanks for writing that up. If you are interested I also implemented the cross-package parallelism idea in hadrian. |
|
I would absolutely love to have support for cross-package parallelism. That would make it much easier to break things into separate packages in our Large Work Repo without negatively harming compilation time. |
|
Anything is better than a new custom Setup.hs type. :) Please feel free to mock up a PR. |
gbaz
added
attention: pr-welcome
attention: needs-help
This was referenced Mar 5, 2023
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Mar 13, 2023
There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a
compiler > ghc-9.4.* then we will attempt to start a multi-session
which loads the selected targets into one multi-package session of
GHC.
1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. It is necessary to modify `./Setup configure` to allow users to
configure a package *without* having previously built the dependency.
Instead, we promise to the configure phase that we will have built it
by the time we build the package. This allows us to configure all the
packages we intend to load into the repl without building any
dependenices which we will load in the same session, because the
promise is satisifed due to loading the package and it's dependency
into one multi-session which ensures the dependency is built before
it is needed.
A user of ./Setup configure specifies a promised dependency by
using the "--promised-dependency" flag with a normal dependency specification. For example:
```
'--promised-dependency=cabal-install-solver=cabal-install-solver-3.9.0.0-inplace'
```
2a. The `./Setup repl` command is modified to allow a user to defer
starting the repl and instead instruct the command to write the
necessary build flags to a file. The option is called
`--repl-multi-file <FILEPATH>`.
`cabal-install` then invokes this command for each component which
will populate the session and starts a multi-session with all the
arguments together.
3. The solver is unmodified, the solver is given the repl targets and
creates a build plan as before. After the solver is completed then in
`setRootTargets` and `pruneInstallPlan` we modify the install plan to
enforce the closure property and mark which dependencies need to be
promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which
indicates to the compiler that it is to be built in a GHC
multi-session.
* Augment the component repl targets to indicate that components
required by the closure property (in addition to normal targets)
will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate
which dependencies are the promised ones (which is precisely
components which are `BuildInPlaceOnly InMemory` build styles).
This is the field which is eventually used to populate the
`--dependency` argument to `./Setup configure`.
Fixes haskell#8491
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Mar 13, 2023
There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a
compiler > ghc-9.4.* then we will attempt to start a multi-session
which loads the selected targets into one multi-package session of
GHC.
1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. It is necessary to modify `./Setup configure` to allow users to
configure a package *without* having previously built the dependency.
Instead, we promise to the configure phase that we will have built it
by the time we build the package. This allows us to configure all the
packages we intend to load into the repl without building any
dependenices which we will load in the same session, because the
promise is satisifed due to loading the package and it's dependency
into one multi-session which ensures the dependency is built before
it is needed.
A user of ./Setup configure specifies a promised dependency by
using the "--promised-dependency" flag with a normal dependency specification. For example:
```
'--promised-dependency=cabal-install-solver=cabal-install-solver-3.9.0.0-inplace'
```
2a. The `./Setup repl` command is modified to allow a user to defer
starting the repl and instead instruct the command to write the
necessary build flags to a file. The option is called
`--repl-multi-file <FILEPATH>`.
`cabal-install` then invokes this command for each component which
will populate the session and starts a multi-session with all the
arguments together.
3. The solver is unmodified, the solver is given the repl targets and
creates a build plan as before. After the solver is completed then in
`setRootTargets` and `pruneInstallPlan` we modify the install plan to
enforce the closure property and mark which dependencies need to be
promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which
indicates to the compiler that it is to be built in a GHC
multi-session.
* Augment the component repl targets to indicate that components
required by the closure property (in addition to normal targets)
will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate
which dependencies are the promised ones (which is precisely
components which are `BuildInPlaceOnly InMemory` build styles).
This is the field which is eventually used to populate the
`--dependency` argument to `./Setup configure`.
Fixes haskell#8491
TristanCacqueray
pushed a commit
to TristanCacqueray/cabal
that referenced
this issue
Mar 16, 2023
There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a
compiler > ghc-9.4.* then we will attempt to start a multi-session
which loads the selected targets into one multi-package session of
GHC.
1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. It is necessary to modify `./Setup configure` to allow users to
configure a package *without* having previously built the dependency.
Instead, we promise to the configure phase that we will have built it
by the time we build the package. This allows us to configure all the
packages we intend to load into the repl without building any
dependenices which we will load in the same session, because the
promise is satisifed due to loading the package and it's dependency
into one multi-session which ensures the dependency is built before
it is needed.
A user of ./Setup configure specifies a promised dependency by
using the "--promised-dependency" flag with a normal dependency specification. For example:
```
'--promised-dependency=cabal-install-solver=cabal-install-solver-3.9.0.0-inplace'
```
2a. The `./Setup repl` command is modified to allow a user to defer
starting the repl and instead instruct the command to write the
necessary build flags to a file. The option is called
`--repl-multi-file <FILEPATH>`.
`cabal-install` then invokes this command for each component which
will populate the session and starts a multi-session with all the
arguments together.
3. The solver is unmodified, the solver is given the repl targets and
creates a build plan as before. After the solver is completed then in
`setRootTargets` and `pruneInstallPlan` we modify the install plan to
enforce the closure property and mark which dependencies need to be
promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which
indicates to the compiler that it is to be built in a GHC
multi-session.
* Augment the component repl targets to indicate that components
required by the closure property (in addition to normal targets)
will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate
which dependencies are the promised ones (which is precisely
components which are `BuildInPlaceOnly InMemory` build styles).
This is the field which is eventually used to populate the
`--dependency` argument to `./Setup configure`.
Fixes haskell#8491
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Mar 21, 2023
There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a
compiler > ghc-9.4.* then we will attempt to start a multi-session
which loads the selected targets into one multi-package session of
GHC.
1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. It is necessary to modify `./Setup configure` to allow users to
configure a package *without* having previously built the dependency.
Instead, we promise to the configure phase that we will have built it
by the time we build the package. This allows us to configure all the
packages we intend to load into the repl without building any
dependenices which we will load in the same session, because the
promise is satisifed due to loading the package and it's dependency
into one multi-session which ensures the dependency is built before
it is needed.
A user of ./Setup configure specifies a promised dependency by
using the "--promised-dependency" flag with a normal dependency specification. For example:
```
'--promised-dependency=cabal-install-solver=cabal-install-solver-3.9.0.0-inplace'
```
2a. The `./Setup repl` command is modified to allow a user to defer
starting the repl and instead instruct the command to write the
necessary build flags to a file. The option is called
`--repl-multi-file <FILEPATH>`.
`cabal-install` then invokes this command for each component which
will populate the session and starts a multi-session with all the
arguments together.
3. The solver is unmodified, the solver is given the repl targets and
creates a build plan as before. After the solver is completed then in
`setRootTargets` and `pruneInstallPlan` we modify the install plan to
enforce the closure property and mark which dependencies need to be
promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which
indicates to the compiler that it is to be built in a GHC
multi-session.
* Augment the component repl targets to indicate that components
required by the closure property (in addition to normal targets)
will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate
which dependencies are the promised ones (which is precisely
components which are `BuildInPlaceOnly InMemory` build styles).
This is the field which is eventually used to populate the
`--dependency` argument to `./Setup configure`.
Fixes haskell#8491
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Mar 22, 2023
There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a
compiler > ghc-9.4.* then we will attempt to start a multi-session
which loads the selected targets into one multi-package session of
GHC.
1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. It is necessary to modify `./Setup configure` to allow users to
configure a package *without* having previously built the dependency.
Instead, we promise to the configure phase that we will have built it
by the time we build the package. This allows us to configure all the
packages we intend to load into the repl without building any
dependenices which we will load in the same session, because the
promise is satisifed due to loading the package and it's dependency
into one multi-session which ensures the dependency is built before
it is needed.
A user of ./Setup configure specifies a promised dependency by
using the "--promised-dependency" flag with a normal dependency specification. For example:
```
'--promised-dependency=cabal-install-solver=cabal-install-solver-3.9.0.0-inplace'
```
2a. The `./Setup repl` command is modified to allow a user to defer
starting the repl and instead instruct the command to write the
necessary build flags to a file. The option is called
`--repl-multi-file <FILEPATH>`.
`cabal-install` then invokes this command for each component which
will populate the session and starts a multi-session with all the
arguments together.
3. The solver is unmodified, the solver is given the repl targets and
creates a build plan as before. After the solver is completed then in
`setRootTargets` and `pruneInstallPlan` we modify the install plan to
enforce the closure property and mark which dependencies need to be
promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which
indicates to the compiler that it is to be built in a GHC
multi-session.
* Augment the component repl targets to indicate that components
required by the closure property (in addition to normal targets)
will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate
which dependencies are the promised ones (which is precisely
components which are `BuildInPlaceOnly InMemory` build styles).
This is the field which is eventually used to populate the
`--dependency` argument to `./Setup configure`.
Fixes haskell#8491
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Mar 22, 2023
There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a
compiler > ghc-9.4.* then we will attempt to start a multi-session
which loads the selected targets into one multi-package session of
GHC.
1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. It is necessary to modify `./Setup configure` to allow users to
configure a package *without* having previously built the dependency.
Instead, we promise to the configure phase that we will have built it
by the time we build the package. This allows us to configure all the
packages we intend to load into the repl without building any
dependenices which we will load in the same session, because the
promise is satisifed due to loading the package and it's dependency
into one multi-session which ensures the dependency is built before
it is needed.
A user of ./Setup configure specifies a promised dependency by
using the "--promised-dependency" flag with a normal dependency specification. For example:
```
'--promised-dependency=cabal-install-solver=cabal-install-solver-3.9.0.0-inplace'
```
2a. The `./Setup repl` command is modified to allow a user to defer
starting the repl and instead instruct the command to write the
necessary build flags to a file. The option is called
`--repl-multi-file <FILEPATH>`.
`cabal-install` then invokes this command for each component which
will populate the session and starts a multi-session with all the
arguments together.
3. The solver is unmodified, the solver is given the repl targets and
creates a build plan as before. After the solver is completed then in
`setRootTargets` and `pruneInstallPlan` we modify the install plan to
enforce the closure property and mark which dependencies need to be
promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which
indicates to the compiler that it is to be built in a GHC
multi-session.
* Augment the component repl targets to indicate that components
required by the closure property (in addition to normal targets)
will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate
which dependencies are the promised ones (which is precisely
components which are `BuildInPlaceOnly InMemory` build styles).
This is the field which is eventually used to populate the
`--dependency` argument to `./Setup configure`.
Fixes haskell#8491
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Mar 22, 2023
There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a
compiler > ghc-9.4.* then we will attempt to start a multi-session
which loads the selected targets into one multi-package session of
GHC.
1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. It is necessary to modify `./Setup configure` to allow users to
configure a package *without* having previously built the dependency.
Instead, we promise to the configure phase that we will have built it
by the time we build the package. This allows us to configure all the
packages we intend to load into the repl without building any
dependenices which we will load in the same session, because the
promise is satisifed due to loading the package and it's dependency
into one multi-session which ensures the dependency is built before
it is needed.
A user of ./Setup configure specifies a promised dependency by
using the "--promised-dependency" flag with a normal dependency specification. For example:
```
'--promised-dependency=cabal-install-solver=cabal-install-solver-3.9.0.0-inplace'
```
2a. The `./Setup repl` command is modified to allow a user to defer
starting the repl and instead instruct the command to write the
necessary build flags to a file. The option is called
`--repl-multi-file <FILEPATH>`.
`cabal-install` then invokes this command for each component which
will populate the session and starts a multi-session with all the
arguments together.
3. The solver is unmodified, the solver is given the repl targets and
creates a build plan as before. After the solver is completed then in
`setRootTargets` and `pruneInstallPlan` we modify the install plan to
enforce the closure property and mark which dependencies need to be
promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which
indicates to the compiler that it is to be built in a GHC
multi-session.
* Augment the component repl targets to indicate that components
required by the closure property (in addition to normal targets)
will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate
which dependencies are the promised ones (which is precisely
components which are `BuildInPlaceOnly InMemory` build styles).
This is the field which is eventually used to populate the
`--dependency` argument to `./Setup configure`.
Fixes haskell#8491
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Mar 22, 2023
There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a
compiler > ghc-9.4.* then we will attempt to start a multi-session
which loads the selected targets into one multi-package session of
GHC.
1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. It is necessary to modify `./Setup configure` to allow users to
configure a package *without* having previously built the dependency.
Instead, we promise to the configure phase that we will have built it
by the time we build the package. This allows us to configure all the
packages we intend to load into the repl without building any
dependenices which we will load in the same session, because the
promise is satisifed due to loading the package and it's dependency
into one multi-session which ensures the dependency is built before
it is needed.
A user of ./Setup configure specifies a promised dependency by
using the "--promised-dependency" flag with a normal dependency specification. For example:
```
'--promised-dependency=cabal-install-solver=cabal-install-solver-3.9.0.0-inplace'
```
2a. The `./Setup repl` command is modified to allow a user to defer
starting the repl and instead instruct the command to write the
necessary build flags to a file. The option is called
`--repl-multi-file <FILEPATH>`.
`cabal-install` then invokes this command for each component which
will populate the session and starts a multi-session with all the
arguments together.
3. The solver is unmodified, the solver is given the repl targets and
creates a build plan as before. After the solver is completed then in
`setRootTargets` and `pruneInstallPlan` we modify the install plan to
enforce the closure property and mark which dependencies need to be
promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which
indicates to the compiler that it is to be built in a GHC
multi-session.
* Augment the component repl targets to indicate that components
required by the closure property (in addition to normal targets)
will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate
which dependencies are the promised ones (which is precisely
components which are `BuildInPlaceOnly InMemory` build styles).
This is the field which is eventually used to populate the
`--dependency` argument to `./Setup configure`.
Fixes haskell#8491
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Apr 12, 2023
There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a
compiler > ghc-9.4.* then we will attempt to start a multi-session
which loads the selected targets into one multi-package session of
GHC.
1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. The solver is unmodified, the solver is given the repl targets and
creates a build plan as before. After the solver is completed then in
`setRootTargets` and `pruneInstallPlan` we modify the install plan to
enforce the closure property and mark which dependencies need to be
promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which
indicates to the compiler that it is to be built in a GHC
multi-session.
* Augment the component repl targets to indicate that components
required by the closure property (in addition to normal targets)
will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate
which dependencies are the promised ones (which is precisely
components which are `BuildInPlaceOnly InMemory` build styles).
This is the field which is eventually used to populate the
`--dependency` argument to `./Setup configure`.
Fixes haskell#8491
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Apr 12, 2023
There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a
compiler > ghc-9.4.* then we will attempt to start a multi-session
which loads the selected targets into one multi-package session of
GHC.
1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. The solver is unmodified, the solver is given the repl targets and
creates a build plan as before. After the solver is completed then in
`setRootTargets` and `pruneInstallPlan` we modify the install plan to
enforce the closure property and mark which dependencies need to be
promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which
indicates to the compiler that it is to be built in a GHC
multi-session.
* Augment the component repl targets to indicate that components
required by the closure property (in addition to normal targets)
will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate
which dependencies are the promised ones (which is precisely
components which are `BuildInPlaceOnly InMemory` build styles).
This is the field which is eventually used to populate the
`--dependency` argument to `./Setup configure`.
Fixes haskell#8491
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Apr 12, 2023
There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a
compiler > ghc-9.4.* then we will attempt to start a multi-session
which loads the selected targets into one multi-package session of
GHC.
1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. The solver is unmodified, the solver is given the repl targets and
creates a build plan as before. After the solver is completed then in
`setRootTargets` and `pruneInstallPlan` we modify the install plan to
enforce the closure property and mark which dependencies need to be
promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which
indicates to the compiler that it is to be built in a GHC
multi-session.
* Augment the component repl targets to indicate that components
required by the closure property (in addition to normal targets)
will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate
which dependencies are the promised ones (which is precisely
components which are `BuildInPlaceOnly InMemory` build styles).
This is the field which is eventually used to populate the
`--dependency` argument to `./Setup configure`.
Fixes haskell#8491
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Apr 17, 2023
There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a
compiler > ghc-9.4.* then we will attempt to start a multi-session
which loads the selected targets into one multi-package session of
GHC.
1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. The solver is unmodified, the solver is given the repl targets and
creates a build plan as before. After the solver is completed then in
`setRootTargets` and `pruneInstallPlan` we modify the install plan to
enforce the closure property and mark which dependencies need to be
promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which
indicates to the compiler that it is to be built in a GHC
multi-session.
* Augment the component repl targets to indicate that components
required by the closure property (in addition to normal targets)
will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate
which dependencies are the promised ones (which is precisely
components which are `BuildInPlaceOnly InMemory` build styles).
This is the field which is eventually used to populate the
`--dependency` argument to `./Setup configure`.
Fixes haskell#8491
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Apr 17, 2023
There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a
compiler > ghc-9.4.* then we will attempt to start a multi-session
which loads the selected targets into one multi-package session of
GHC.
1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. The solver is unmodified, the solver is given the repl targets and
creates a build plan as before. After the solver is completed then in
`setRootTargets` and `pruneInstallPlan` we modify the install plan to
enforce the closure property and mark which dependencies need to be
promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which
indicates to the compiler that it is to be built in a GHC
multi-session.
* Augment the component repl targets to indicate that components
required by the closure property (in addition to normal targets)
will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate
which dependencies are the promised ones (which is precisely
components which are `BuildInPlaceOnly InMemory` build styles).
This is the field which is eventually used to populate the
`--dependency` argument to `./Setup configure`.
Fixes haskell#8491
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Apr 20, 2023
There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a
compiler > ghc-9.4.* then we will attempt to start a multi-session
which loads the selected targets into one multi-package session of
GHC.
1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. The solver is unmodified, the solver is given the repl targets and
creates a build plan as before. After the solver is completed then in
`setRootTargets` and `pruneInstallPlan` we modify the install plan to
enforce the closure property and mark which dependencies need to be
promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which
indicates to the compiler that it is to be built in a GHC
multi-session.
* Augment the component repl targets to indicate that components
required by the closure property (in addition to normal targets)
will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate
which dependencies are the promised ones (which is precisely
components which are `BuildInPlaceOnly InMemory` build styles).
This is the field which is eventually used to populate the
`--dependency` argument to `./Setup configure`.
Fixes haskell#8491
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Apr 20, 2023
There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a
compiler > ghc-9.4.* then we will attempt to start a multi-session
which loads the selected targets into one multi-package session of
GHC.
1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. The solver is unmodified, the solver is given the repl targets and
creates a build plan as before. After the solver is completed then in
`setRootTargets` and `pruneInstallPlan` we modify the install plan to
enforce the closure property and mark which dependencies need to be
promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which
indicates to the compiler that it is to be built in a GHC
multi-session.
* Augment the component repl targets to indicate that components
required by the closure property (in addition to normal targets)
will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate
which dependencies are the promised ones (which is precisely
components which are `BuildInPlaceOnly InMemory` build styles).
This is the field which is eventually used to populate the
`--dependency` argument to `./Setup configure`.
Fixes haskell#8491
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Apr 20, 2023
There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a
compiler > ghc-9.4.* then we will attempt to start a multi-session
which loads the selected targets into one multi-package session of
GHC.
1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. The solver is unmodified, the solver is given the repl targets and
creates a build plan as before. After the solver is completed then in
`setRootTargets` and `pruneInstallPlan` we modify the install plan to
enforce the closure property and mark which dependencies need to be
promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which
indicates to the compiler that it is to be built in a GHC
multi-session.
* Augment the component repl targets to indicate that components
required by the closure property (in addition to normal targets)
will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate
which dependencies are the promised ones (which is precisely
components which are `BuildInPlaceOnly InMemory` build styles).
This is the field which is eventually used to populate the
`--dependency` argument to `./Setup configure`.
Fixes haskell#8491
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
May 2, 2023
There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a
compiler > ghc-9.4.* then we will attempt to start a multi-session
which loads the selected targets into one multi-package session of
GHC.
1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. The solver is unmodified, the solver is given the repl targets and
creates a build plan as before. After the solver is completed then in
`setRootTargets` and `pruneInstallPlan` we modify the install plan to
enforce the closure property and mark which dependencies need to be
promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which
indicates to the compiler that it is to be built in a GHC
multi-session.
* Augment the component repl targets to indicate that components
required by the closure property (in addition to normal targets)
will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate
which dependencies are the promised ones (which is precisely
components which are `BuildInPlaceOnly InMemory` build styles).
This is the field which is eventually used to populate the
`--dependency` argument to `./Setup configure`.
Fixes haskell#8491
fgaz
pushed a commit
to mpickering/cabal
that referenced
this issue
May 25, 2023
There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a
compiler > ghc-9.4.* then we will attempt to start a multi-session
which loads the selected targets into one multi-package session of
GHC.
1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. The solver is unmodified, the solver is given the repl targets and
creates a build plan as before. After the solver is completed then in
`setRootTargets` and `pruneInstallPlan` we modify the install plan to
enforce the closure property and mark which dependencies need to be
promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which
indicates to the compiler that it is to be built in a GHC
multi-session.
* Augment the component repl targets to indicate that components
required by the closure property (in addition to normal targets)
will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate
which dependencies are the promised ones (which is precisely
components which are `BuildInPlaceOnly InMemory` build styles).
This is the field which is eventually used to populate the
`--dependency` argument to `./Setup configure`.
Fixes haskell#8491
fgaz
pushed a commit
to mpickering/cabal
that referenced
this issue
May 25, 2023
There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a
compiler > ghc-9.4.* then we will attempt to start a multi-session
which loads the selected targets into one multi-package session of
GHC.
1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. The solver is unmodified, the solver is given the repl targets and
creates a build plan as before. After the solver is completed then in
`setRootTargets` and `pruneInstallPlan` we modify the install plan to
enforce the closure property and mark which dependencies need to be
promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which
indicates to the compiler that it is to be built in a GHC
multi-session.
* Augment the component repl targets to indicate that components
required by the closure property (in addition to normal targets)
will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate
which dependencies are the promised ones (which is precisely
components which are `BuildInPlaceOnly InMemory` build styles).
This is the field which is eventually used to populate the
`--dependency` argument to `./Setup configure`.
Fixes haskell#8491
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now there is a limitation to cabal which means that you have to build all a packages dependencies before configuring a package. When combined with multiple home units this is a serious issue because you have to build all the packages first before you start your multi-component session which then builds them again. This limitation makes multi-component unsuitable as a means of doing builds for example (as much work is duplicated).
In addition, for clients such as HLS, which has support for multi-component sessions, having to build everything before discovering the options is sub-optimal (for the same reason, the build will be completed again by HLS).
So it would be good to find a way to configure all the packages we're going to build before we actually build any of them. There are two problems to overcome:
Problem 1: Setup.hs scripts might depends on the assumption that all dependencies are built (for example might consult the package database to look at the abi of a dependency).
Problem 2: The Setup.hs configure logic requires that a package has been built (and in the package database) for the configure step to work.
The proposed solution to these issues is:
Setup.hsrequires the dependencies to be already built or not before configuring. Almost all customSetup.hsdo not require dependencies to have been built.The text was updated successfully, but these errors were encountered: