On Wed, 2009-12-23 at 21:49 +0000, Simon Marlow wrote:

I personally think we should revert to using the standard config.guess and normalising the result as we used to.

Aye.

It was changed due to this:

http://hackage.haskell.org/trac/ghc/ticket/1717

so we should find another way around that.

I think we should just tell the ppc linux people to get their change to config.guess pushed upstream. They cannot expect to change every package instead. Duncan

On 24/12/09 14:01, Ian Lynagh wrote:

On Wed, Dec 23, 2009 at 09:49:40PM +0000, Simon Marlow wrote:

...

On 22/12/09 12:59, Jens Petersen wrote:

...

2009/12/19 Kirill A. Shutemov:

...

I want to build ghc for i586-alt-linux-gnu.

Why? :)

...

Why do not use config.guess to guess correct host/target/build instead of reinvent wheel?

While I sympathize (I gave up long ago trying to use host/target/build with ghc - we use them by default in Fedora) - I guess the short answer is something like cross-compiling is not supported or the effort to support host/target/build is more than the win? But those are just my assumptions - I leave a real answer to a ghc buildsystem expert.

If you really want a fix searching trac and opening a ticket would be more effective probably.

I personally think we should revert to using the standard config.guess and normalising the result as we used to.

I don't see the advantage. Before we had 484 lines of case expression in configure.ac, which now and again needed tweaking to keep up with changes in configure.

Now we don't need to be told the platform that we are building for, as we just ask the bootstrapping compiler what platform it builds for, and we only support building for that platform anyway. If you specify a different platform then the build will break. I don't know if the original poster means that he wants i586 as opposed to e.g. i386 (to make use of newer instructions or to optimise differently), but if so we don't do anything different for different subarches.

As far as I can see, the only reason we would need to support all the platform values that configure supports is if/when we are going to support cross-compilation.

Yes, that's the main reason. Eventually we will want to do cross-compilation, so I think it makes sense to retain the possibility. There's also the reason that people are building GHC in environments that expect to be able to pass GNU-standard --host options to configure. The normalisation doesn't necessarily need to be as long or complicated as it was before: we could normalise the machine and os separately, and ignore the vendor. We should check that the bootstrapping GHC agrees with the build platform. Cheers, Simon