patch applied (packages/regex-base): Make setupscriptcompileagain after recent Cabal changes

Claus Reinke claus.reinke at talk21.com
Sun Sep 2 18:10:04 EDT 2007


>>     -- P.cabal
>>     Exposed-modules: Data
>>     Build-Depends:  base, time
>> 
>>     -- Data.hs (yes..)
>>     module Data(module Time) where
>>     import Data.Time as Time
> 
> I'm a bit confused; is this Data module necessary? If so, is its name
> important? Are you proposing a new extension?

for context: 

- i suggested that there should be a base package that would
    depend on the packages split off from the old base, and would
    simply reexport their modules to provide the full functionality of 
    the old base on top of the spin-off packages

- Ross pointed out that packages can't simply re-export modules, 
    so the straightforward solution of a package without sources, 
    just with a .cabal file, seems barred for the moment (though i
    don't understand why this restriction is there, so perhaps i am
    asking for an extension?)

- taking time as a small example, i was looking for a way around
    this limitation, to reexport time's modules via a different package:

    - it seems that cabal needs some sources for exported modules
    - module Data.Time where import Data.Time,
        then exposing Data.Time, does not work, because of cycle
    - module Data(module Time) import Data.Time as Time,
        then exposing Data, does work, as demonstrated

>> configure, build, install, and 'ghc -package P Y.hs' seems to work.
>>     $ ghc -package P Y.hs
> 
> Why is -package P better than -package time? 

not better, it just demonstrates that we can re-export a module
from package time via package P. so, presumably, one could
re-export the modules distributed over the packages split off
from the old base via a thin package base, avoiding breakage.
 
there may be other ways, i just needed one way to confirm 
that it is possible.

claus



More information about the Libraries mailing list