As usual: Directory problems
sven.panne at aedion.de
Sat Sep 15 10:43:42 EDT 2007
Like every weekend when I try to build a GHC RPM, things have been broken
again, this time by ghc-pkg not taking DESTDIR into account, but the details
do not matter. Fixing the RPM build every weekend again and again and again
is extremely frustrating. What can we do to improve this? "make validate" is
obviously not enough.
First of all, I think there have to be automatic nightly RPM builds, using the
ghc.spec from the repository (well, a configured version of it). Are there
any volunteers to set this up? Although I have a continuously running Linux
server hosted at a provider, its RAM is far too small for building GHC, so
this is no option.
Furthermore, the root of all evil is the arcane logic regarding paths in our
build system/tools, which has over the years grown beyond anything a single
sane human can comprehend. For a proof of this, just look at the number of
commits having to do with fixing build/install/Haddock/whatever paths.
Therefore I think that this area need some *serious* cleanup. I suggest the
* We have to adhere *strictly* to GNU convention, so lines like
datadir := $(datadir0)/ghc-$(ProjectVersion)
libdir := $(libdir0)/ghc-$(ProjectVersion)
are a complete no-no. This would have 2 advantages: a) Everybody knows
immediately what e.g. "$(libdir)" means. b) Deviating from GNU standards will
undoubtely lead to bug reports for packagers later. Responding with "libdir
has a totally different meaning for our project" is not OK.
* We have to make ourselves, the Makefiles and the tools aware of the fact
that there are *3* kind of paths: paths at build time, paths at temporary
installation time (normally below DESTDIR, where rpmbuild picks things up),
and paths at final installation time (nomally below /usr and friends, done by
e.g. rpm). Currently there are a few hacks in our system, e.g. ghc-pkg is
validating final installation paths at temporary installation time, which of
course fails (unless the $topdir hack in ghc-pkg is triggered). Perhaps some
options are missing in the tools? What is $topdir all about? When should we
substitute what into which paths? This is all done in a very ad-hoc fashion
* Windows installations seem to be a very special beast, so we should
collect all those deviations from the GNU standards in a single place, so it
is very obvious where we willingly deviate from the standards.
P.S.: To be exact, there is even one more kind of path when we take
relocatable RPMs into account, but these can be handled in the .spec file via
some sed magic.
P.P.S.: </RantMode> ;-)
More information about the Cvs-ghc