Hi James, * James Laird wrote on Tue, Mar 28, 2006 at 07:50:53PM CEST: > > When the AC_TRY_RUN macro runs a program, it invokes it with the simple > command > ./a.out > When cross-compiling, obviously, this test will fail or produce output > that isn't correct for the target platform. > > However, on some multiprocessor machines with a separate execution node, > it's possible to run test executables if they're preceded by a special > invocation command. For instance, > yod ./a.out > will run and produce informative results. Interesting. What kind of system is this, if I may ask? > For our automated tests, we set a value we call RUNSERIAL to invoke each > test (using either a homebrew invocation or automake's TEST_ENVIRONMENT > variable). It would be great if we could do the same thing in configure. There have been several[1] calls for or attempts to get functionality into Autoconf that - allows to start a simulator to execute binaries for $host, - allows to transfer binaries (and possibly other needed files, like configuration files, or needed shared libraries) to another host which may then execute the binary. - use a chroot, or whatnotelse, to setup a $host environment, ... None of the attempts have been complete, in the sense that they tried to solve the issue for more than just their specific setup at hand (IIRC I'm echoing Paul here). I actually tried to look into this a few weeks ago and decided after reading that I still did not know enough about the problem space to be able to propose a good solution in a short amount of time. (For example, transferring multiple binaries may be magnitudes faster than doing all round trips for every test; or: how would you handle the need to authenticate? How would you actually make sure the needed shared libraries are already installed and not just visible from the $build system?) Some packages offer a separate script/binary to run/compile on the $host system that collects various data and writes them out in a way suitable for use as config.cache or config.site file. For configure tests, this is a pretty good workaround. I think it'd be a good idea to look at this issue again sometime after 2.60. Cheers, Ralf [1] See http://thread.gmane.org/gmane.comp.sysutils.autoconf.general/6274 and the two complete threads referenced therein; or http://article.gmane.org/gmane.comp.sysutils.autoconf.general/6281 for a similar question with Autotest, which is similar to yours :) _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
