On Mon, Sep 21, 2009 at 7:37 PM, <Ralf.Wildenhues@xxxxxx> wrote: > * Steffen Dettmer wrote on Mon, Sep 21, 2009 at 10:24:26AM CEST: > > > 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 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. I think I /technically/ understand what you explain. We have typically 40 sub-configures, where first exports include paths for 39 subsequent, 2nd for 38 and so on - using cache variables. When an export changes, the cache variable is updated and without calling predecessor-config the importing module is up-to-date. Saves much time on cygwin. Similar to that we could have a component setting all the cache variables, ok. But what should this help? We had to write the tests ourselfs (just not inside autoconf) to seed the values? So /logically/ I don't understand. We use autoconf to find out if we have printf and/or malloc and so on. We do not want to manually have to tell if we have it or not. Writing the test results in advance seems to render the whole test a bit useless? > 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. You mean someone could manually change config.status or config.site? Wouldn't this be horrible and violating reproducibility? Or would this site file be included in version control and source dist? I think, when building, no adjustments are allowed. In case of a problem the sources have to be fixed, a new tag must be set and the build started again from scratch. Also, I think, config.site may not be suited for cross-compiling. oki, Steffen _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf