Adds virtual-modules to handle cases like GHC.Prim from ghc-prim.
#4875
Conversation
|
How much documentation would this need? |
|
I'm a bit conflicted about this... yet another magic undocumented logic... what if I have a custom package which happens to define a module named |
|
Hmm, so now I can't make a package that has a module named |
|
Btw, to makes things more interesting, |
|
I'm not terribly happy with this either. For I therefore plan to go forward with a guard on the |
Most likely none, but at least you won't need to patch Cabal again if |
I believe |
angerman
force-pushed
the
feature/ghc-prim
branch
from
63db5ea to
fd54252
Compare
angerman
changed the title
virtual-modules to handle cases like GHC.Prim from ghc-prim.
GHC's `ghc-prim` package has an `exposed-module` for which there exists no source code. As such it can't be built and has no interface file. With the goal of getting rid of hacks in GHC `ghc-prim`s cabal file, which does the following:
```
flag include-ghc-prim
Description: Include GHC.Prim in exposed-modules
default: False
[...]
if flag(include-ghc-prim)
exposed-modules: GHC.Prim
```
and has this explaination in the build system:
```
# ----------------------------------------
# Special magic for the ghc-prim package
# We want the ghc-prim package to include the GHC.Prim module when it
# is registered, but not when it is built, because GHC.Prim is not a
# real source module, it is built-in to GHC. The old build system did
# this using Setup.hs, but we can't do that here, so we have a flag to
# enable GHC.Prim in the .cabal file (so that the ghc-prim package
# remains compatible with the old build system for the time being).
# GHC.Prim module in the ghc-prim package with a flag:
#
libraries/ghc-prim_CONFIGURE_OPTS += --flag=include-ghc-prim
# And then we strip it out again before building the package:
define libraries/ghc-prim_PACKAGE_MAGIC
libraries/ghc-prim_dist-install_MODULES := $$(filter-out GHC.Prim,$$(libraries/ghc-prim_dist-install_MODULES))
endef
```
The addition of the `virtual-modules` has thus the effect of a module that is assumed to exist
but not tried to be built or listed in any of the module files. It is however part of the
`exposed-modules` when registered into the package database
angerman
force-pushed
the
feature/ghc-prim
branch
from
fd54252 to
3623270
Compare
|
I'll do some more test, and merge if nothing falls through the cracks. |
|
Seems to work for me as expected. |
…res, extra-library-flavours, and virtual-modules. As pointed out by @hvr, haskell#4857, haskell#4875 did not contain the necessary "check" logic. This PR tries to address this shortcoming.
Stop the GHC.Prim madness with `virtual-module` support from cabal. Needs haskell/cabal#4875. Bumps submodule libraries/Cabal to include the necessary logic for `virtual-module`. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4179
This used to be done in
ghc-cabal. With the long term goal of getting rid of ghc-cabal eventually, it's functionality needs to end up in cabal.While this is a custom hack, it is restricted to the GHC module only. A more generic solution would be to add
virtual-modulesI suppose. GHC does custom handling forGHC.Prim, and there is no support forvirtual-modulesin the package config file either as far as I can see. As such this seems to be the least invasive solution.Please include the following checklist in your PR:
[ci skip]is used to avoid triggering the build bots.Please also shortly describe how you tested your change. Bonus points for added tests!