Use standard mechanism to tell ./configure the c-compiler

[hvr]

Most Autoconf configure scripts don't support the non-standard --with-gcc
flag, and there does not seem to be any good reason to do so, since
Autoconf has already a proper way to set the c-compiler:

Either via the CC environment variable, or (with higher precedence)
by passing a commandline argument of the form CC=clang-3.8.

This patch simply replaces the previous non-standard --with-gcc=clang-3.8
argument (which was clearly misnamed to begin with) by a CC=clang-3.8
command-line argument to the configure script.

[hvr]

For the record, --with-gcc= was added via 95f0488
but I'm convinced that was the wrong way to do this already back then.

[23Skidoo]

+1, but don't we need to keep --with-gcc for backwards compat?

[hvr]

I don't think we need to keep --with-gcc around, as the few configure scripts that actually implement --with-ghc do something like

AC_ARG_WITH([gcc],
            [C compiler],
            [CC=$withval])

So, if we got such a configure script, passing CC=<some-c-compiler> instead of --with-gcc=<some-compiler> will do the right thing. It can actually help to avoid some bugs. For instance, the unix package implements a --with-cc option just like the AC_ARG_WITH example above (but for cc rather than gcc). And calling unix's configure script like

$ ./configure --with-cc clang-3.8
configure: WARNING: you should use --build, --host, --target
checking for clang-3.8-gcc... yes
checking whether the C compiler works...  *HANG*

let's the configure script hang at compiler detection, and fill up config.log until hdd space is exhausted... :-/

And before that, I refactored a configure.ac file and accidentally triggered AC_PROG_CC too early before the --with-cc option was interpreted, causing cross-compilation to break. So I'm convinced that --with-{cc,gcc} is a very bad idea for Autoconf, and more importantly, it's redundant, as there's already a proper way to set the c-compiler.

PS: I'm sure you've noticed something like

Configuring unix-2.7.1.1...
configure: WARNING: unrecognized options: --with-compiler, --with-gcc
...

or

Configuring network-2.6.2.1...
configure: WARNING: unrecognized options: --with-compiler, --with-gcc

which you see for most build-type: configure packages (which also makes them less cross-compile friendly, unless you make sure the CC env-var is properly set).

[23Skidoo]

OK, merged. I guess we should also get rid of --with-compiler as well in favour of something like HC=/path/to/ghc?

[hvr]

@23Skidoo yeah, replacing --with-compiler with HC=... and possibly HCFLAGS=... would be the next logical step...

I've done a quick survey of Hackage, it seems there's only very few packages actually (I counted only 6) implementing --with-compiler, and a couple of those (e.g. time, augeas, and altfloat) just have something like

dnl We don't actually care, but this shuts up the warning.
AC_ARG_WITH([compiler], [AS_HELP_STRING([--with-compiler],
        [specify which Haskell compiler to use])])

in there to shut up that warning... ;-)

the remaining 3 are cuda, cufft and edenmodules which actually use --with-compiler for testing properties of GHC.

In any case, I think we should start passing HC= to ./configure, and maybe keep also passing --with-compiler for a few releases for backward compat.

[23Skidoo]

In any case, I think we should start passing HC= to ./configure, and maybe keep also passing --with-compiler for a few releases for backward compat.

Created a ticket for this.