library infrastructure roundup

[Simon Marlow]

Alastair Reid writes:

> I agree that the decision lies with the people who package=20
> libraries and must=20
> conform with guidelines for the individual platform.  But I=20
> think that=20
> compiler writers can help implement whatever decision those=20
> people make.
>=20
> An easy way of doing this is for compilers to always consult=20
> a configuration=20
> file which says where globally and locally installed=20
> libraries are located. =20

Which is exactly what ghc-pkg does, right?  (modulo the fact that
per-user packages aren't supported well right now).

> A ghc distribution might come with certain default locations=20
> baked into it=20
> but those would be overridden if the configuration file is=20
> found.  This is=20
> easy for people packaging ghc to deal with because all they=20
> have to do is=20
> provide a config file which contains the platform preferences.

You seem to have made a leap here - I still don't see why *another*
configuration file is needed.  The package.conf file that ghc-pkg knows
about contains all the information the compiler needs to know about what
libraries are installed.

> Suppose we do this and you go to install a library.  Where=20
> should the library=20
> be installed?  Obviously, it should go in the place that the platform=20
> maintainers prefer.  How can you find where that is?  By=20
> consulting the configuration file.

Here's where I disagree.

Let's take FreeBSD's ports system as an example.  When it builds
something, it runs the configure script passing an appropriate value for
$prefix.  This is configurable - I can set PREFIX in /etc/make.conf to
change what value is passed to the configure script.

Why should I have to put this information in yet another configuration
file, risking disaster if the two become out of sync?  And why do we
need another mechanism on top of what the ports system already provides?

Cheers,
	Simon