Re: how to support compilers that cannot create executables?

[Ralf Wildenhues]

* Steffen Dettmer wrote on Mon, Sep 21, 2009 at 10:24:26AM CEST:
> On Fri, Sep 18, 2009 at 7:07 PM, Ralf Wildenhues wrote:
> > * Steffen Dettmer wrote on Fri, Sep 18, 2009 at 12:19:19PM CEST:
> > > But because of the tests it would not make much sense to do so, right?
> > > So it is better to have dummy entry code I think.
> > > Sorry for my question, was not though-through.
> >
> > If you cannot write such a wrapper, then it probably makes just as much
> > sense to pre-seed a config.site file with cache variables containing the
> > correct answers for this compiler.
> 
> I'm afraid I don't understand. You mean, we could write the
> results of some specific tests in advance?

Yes.

> What kind of test
> results could that be? What would be the advantage? Even with the
> same compiler, results vary.
> 
>   (For instance, sometimes we have ARM TCC with localtime_r,
>   sometimes without - which actually is a bad example, because
>   sometimes we have and can link localtime_r, but must not use
>   it, which cannot be detected by configure of course).

Well, you'd have one site file per configuration, where, with
configuration, I mean one kind of setup that will cause all relevant
configure tests to have the same set of answers.

For such a configuration, you could take all the cache variables of
all the relevant tests, and pre-seed them.  Then you can load that
site file and work with that configuration.

Recent git Autoconf has added documentation for many cache variables;
but even if you don't know them, you can do a configure run for a very
similar configuration and adjust the results that come out wrong;
that'll usually come close.

The documentation for "Site Configuration" and "Site Defaults" (see
these nodes) has been there for a long time.

Hope that helps.

Cheers,
Ralf