> > It isn't strictly speaking hardcoded, it's set up when you
> configure a
> > binary distribution. So if you move gcc or install a new
> version, you need
> > to re-install ghc.
>
> I understand the technical issues, but the problem is that
> installing/compiling GHC from source is a *pain* (and
> requires you to have a machine with a lot of memory and a
> fast CPU or a spare machine, which you can afford doing
> nothing else for quite a while). So, IMHO, binary
> distributions are *very important* for GHC. I am sure that
> it is clear that a binary distribution with strict
> dependencies on locations of other tools is far from ideal.
I think you misunderstood - a standard GHC binary distribution is
independent of the location of cpp on the target machine. It is discovered
when you unpack the distribution and type './configure'. So, all that's
needed is to re-install the binary distribution.
This probably isn't the case for RPM's, but as you noted in your message
it's up to the package builder to arrange for the location of cpp and other
tools to be configured at install time.
> A (somewhat unsatisfactory) solution for package
> manager-based distributions (like .rpm or .deb) would be to
> use a post-install script that searches for cpp and patches
> the path. To make this easier, it would be nice if the path
> (and any other similar dependencies) where located in a
> dedicated file where they are easy to find and patch.
>
> > I suppose we can put in a configure test for known locations of cpp
> > (/lib/cpp, /usr/libexec/cpp, /usr/lib/cpp) and use that in
> preference to
> > anything else if it works.
>
> Do you mean `./configure' at build time? Or a post-install
> script (in the sense of my above comment).
Both.
Cheers,
Simon
