patch applied (packages/regex-base):Make setupscriptcompileagain
after recent Cabal changes
claus.reinke at talk21.com
Mon Sep 3 13:02:05 EDT 2007
> You have to understand that the above command does two things: it compiles
> Y.hs to Y.o, and then it links Y.o with libraries to form a binary. In the
> first stage, all exposed packages are available (because you didn't say
> -hide-all-packages), so Data.Time from package time is in scope and you can
> successfully import it. At link time, all you have to do is make sure the
> required packages are linked in, and you did that by explicitly linking
> something (P) that depends on package time, so package time was linked in too.
> I don't think there's anything really "wrong" here, that's just the way it
> works when you don't use --make.
ah, thanks! somehow, i had been living under the misconception that,
to get at any non-base package's modules, i would have to use either
--make or -package. as if -hide-all-packages -package base was the
default, in other words. instead, the distinction is exposed vs hidden,
which makes sense. (*)
which means that my test setup was useless, other than supporting
link-time dependency recording. package dependencies are another
matter, since for building packages -hide-all-packages is the default,
and my setup did not, after all, re-export modules as intended.
one might still re-export modules under their original names, by
using two packages. for the time example: a package P can depend
on base and time, importing Data.Time, exposing P.Data.Time; then,
a package Q can depend on base and P, importing P.Data.Time,
exposing Data.Time. with this alternate setup,
ghc -hide-all-packages -package base -package Q Y.hs
succeeds (this time hopefully for the right reasons?-).
if i recall correctly, the grafting/mounting/package-qualifier proposals
were attempting to formalise this linking of package modules into a
module hierarchy, in various ways. perhaps providing package
qualifiers (with a way to disambiguate between package and module
names) could be reconsidered, given that mounting of package
modules in the hierarchy may then be achieved via intermediate
packages like Q above?
(*) still, i find this two-things separation confusing, because the compiler
only "half-knows" about things (being able to compile without complaint,
then fail in linking with confusing errors), and because -package serves
two separate purposes (exposing packages, and enabling linking). i'd
rather keep the illusion that link objects are an internal representation
of source modules, and either both compile and link succeed, or both
fail, with a source-level error message.
More information about the Libraries