> I was recently building ghc-5.00.2 from a cvs download of fptools and
> noticed a few
> glitches, which could be considered documentation issues.
> (The cvs tag
> of the fpconfig &
> ghc was ghc-5-00-2.) The installed version of ghc on my
> RedHat 6.2 linux
> system
> was 4.08.2.
>
> When doing the second build (to build ghci with the new 5.00.2) the
> build failed with
> a report of an unsupported compiler flag "-K2m". I traced this to
> autoconf, which
> in versions before 2.5, cached its results by default. (The configure
> script checks the
> ghc version and since the result is cached, it doesn't get
> updated the
> second time you
> run the build. The build then assumes the wrong version of
> the compiler
> is being used.)
Yes, good point. We normally avoid this by having separate build trees
for the 1st and 2nd stage compilers, using 'lndir' as the build document
describes.
> This could be fixed by specifying in the documentation that
> autoconf 2.5
> or later should
> be used, or that the config.cache file be deleted between builds.
>
> In a build of the fptools according to the latest building guide, the
> ghc/hslibs/green-card/nofib
> projects built more or less OK. Green-card didn't quite clean
> up after
> itself and and
> also had a version mismatch problem on building a second time
> with the
> new 5.00.2.
> I will submit a patch to its makefile.
>
> Since we are interested in using several of the fptools projects
> (especially green-card and
> hood) we will try to get them to build cleanly. Is there interest in
> tagging the projects in the
> cvs that build cleanly as a suite? This might help to counter the
> perception that ghc lacks
> the tools to be a real-world programming system.
Please send patches to [EMAIL PROTECTED] and we'll incorporate them.
Having a tag for a fully working suite would be a good idea, but we
generally find that in order to achieve stability you need to branch and
apply fixes. It might be a better idea to do this in conjunction with a
GHC release - ie. branch green-card and the other tools along the GHC
branch and maintain them together.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
