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