Alastair Reid writes:

I agree that the decision lies with the people who package libraries and must conform with guidelines for the individual platform. But I think that compiler writers can help implement whatever decision those people make.

An easy way of doing this is for compilers to always consult a configuration file which says where globally and locally installed libraries are located.

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 baked into it but those would be overridden if the configuration file is found. This is easy for people packaging ghc to deal with because all they have to do is 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 should the library be installed? Obviously, it should go in the place that the platform maintainers prefer. How can you find where that is? By 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