On 10 May 2005 11:48, Tony Finch wrote:
> On Tue, 10 May 2005, Simon Marlow wrote:
>>
>> 2. The GHC build could start using -fignore-all-packages to
>> insulate itself from the environment (or, simpler but more
>> hacky: -ignore-package lang). This isn't a *solution* as such,
>> because the problem affects everyone, not just us.
>
> I'm slightly surprised that this isn't already the default, and that
> probably explains the recent argument. In the C world the only
> libraries that matter to the build environment are the ones you
> explicitly pull in. Overlaps still matter but only within your
> program. On the other hand Perl's module namespace is global, and a
> (usually implicit) search path is used to resolve conflicts.
FWIW, I tend to agree. -fhide-all-packages should be the default. (I
know that others disagree, though).
> I greatly prefer the former model. Perl is a real pain if you want
> multiple parallel installations of slightly different versions of the
> same code - you effectively need a separate Perl installation for each
> installed version of a program that uses Perl.
>
> Perhaps the missing idea is the package configuration step, during
> which its dependencies are resolved to installed libraries on the
> build machine and any conflicts are dealt with.
Actually this is what we're proposing to do in Cabal. Anyone using
Cabal won't have to worry about these issues, but they will have to
specify all package dependencies explicitly.
> The package is
> shipped with abstract dependencies (module names and perhaps version
> numbers), but by the time the compiler gets involved these have been
> resolved to paths in the file system.
It's a bit higher level than that: the compiler does have an
understanding of packages, but it just maps a package name to a library
and a bunch of interface files. So essentially what you describe is the
way it works (with Cabal, at least).
Cheers,
Simon
