Simon Marlow <[EMAIL PROTECTED]> wrote,
> > > 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.
Sorry, I indeed misunderstood. (It is too long since I
installed a GHC .tar.gz 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.
Correct me, if I am wrong again, but if I remember
correctly, GHC's .tar.gz binary distributions can be
configured either in-situ in one subtree or be made to
install into some other place. Unfortunately, both is
unsuitable for an RPM (or, as far as I know, for a Debian
package). It is a Bad Thing to move files in a RPM
post-install script as one of the nice features of RPM is
that it keeps track of all the install files and allows to
remove complete packages with only a few keystrokes (or
mouse clicks). On the other hand, it is necessary that the
files stored in the RPM are distributed to /usr/bin,
/usr/lib, /usr/doc etc if we want to follow the Linux
installation guidelines - which we definitely want (so
the standard in-situ installation won't do either).
In other words, a Good RPM is snapshot of a selected set of
files scattered over the /usr subtree. The post-install
script should just patch some configuration file. Thus,
> > [...] 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.
One possibility would be to have a `ghc-cpp' script, which
is a one liner and just `exec's cpp. We could either patch
this script or have different versions `ghc-cpp-<arch>',
which are linked to `ghc-cpp'. What do you think?
Cheers,
Manuel
