• Edward Z. Yang's avatar
    Replace the module renaming/thinning system · 1017f710
    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.
Cabal.cabal 21.2 KB