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