-
Edward Z. Yang authored
We had an old implementation of 'ModuleRenaming', with the assumption that it would be used directly in build-depends; since we have dropped this assumption, we can refactor 'ModuleRenaming' and we do so. The main idea is to make the data type more directly reflect the syntax you can specify in a Cabal file; so the default renaming and an explicit thinning renaming are now different constructors. It's no longer possible to use the "with" syntax, but it's not necessary either, since we have a special backpack-includes field to specify renamings, so we don't need them to be Monoidal. There is also a new syntax for 'hiding', which just lets you hide some modules when including a package. Handy! Previously, we recorded 'ModuleRenaming' in @build-depends@, but separated it out when we stored in 'BuildInfo'. We now go even further, by changing it from a 'Map' (the only thing @build-depends@ could support) to a list (so that a package name can be specified multiple times.) This is good because now a user can instantiate something several times, which is useful in Backpack. Also add the new field @backpack-includes@ which can be used to exert fine-grained control over what modules a package brings into scope, include it multiple times, etc. In the .cabal checks, replace 'depsUsingThinningRenamingSyntax' with a more direct check to see if @backpack-includes@ was used. Dropped the legacy 'lookupRenaming' export from ModuleRenaming and PackageDescription; we will shortly not use it anymore. As an intermediate hack we have a local definition in Configure, but this will go away shortly.
1017f710