Improving GMP configure

Niels Möller nisse at lysator.liu.se
Mon Nov 29 20:23:49 CET 2010


Torbjorn Granlund <tg at gmplib.org> writes:

> nisse at lysator.liu.se (Niels Möller) writes:
>
>   Torbjorn Granlund <tg at gmplib.org> writes:
>   
>   > * Add a mechanism for using a default ABI (as already discussed):
>   >
>   >    o Choose compiler according to current rules, then figure out that
>   >      compiler's default ABI.

>   So I'd advocate to let the standard AC_PROG_CC choose the
>   compiler here [...]
>   
>   Under what circumstances do you want a different compiler than
>   AC_PROG_CC?
>   
> I didn't say that.  I don't know if the rejection mechanism are inside
> AC_PROG_CC or if the backtrack AC_PROG_CC from external tests.  But we
> do reject compilers today, based on known bugs, tested from via
> acinclude.m4.

As far as I understand, AC_PROG_CC doesn't do any backtracking, and
gmp's current configure does something more advanced than (and different
from) plain AC_PROG_CC.

After rereading the docs for AC_PROG_CC, one possible approach might be
to keep a list of potential compilers. First detect broken compilers and
strike the from the list. Then invoke AC_PROG_CC with this list. Then
the search AC_PROG_CC wouldn't really be used, but AC_PROG_CC would
still do some useful work in figuring out options for ANSI-C and the
like.

As for backtracking, I don't know how that works or how it ought to
work. To me it seems simpler to do *all* the checks that a compiler
might fail before doing any other checks which depends on the selected
compiler.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.


More information about the gmp-devel mailing list