* 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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
