I am into the crosscompiling thing a lot, and in fact the most common targets are embedded platforms which can not bear a full fledged development environment. Those could not benefit quite from your proposal unless they are big enough to run a compiler which in turn has access to a well-sized filesystem, and all in all with a full network stack in the system, and processing power enough to get an answer in a reasonable roundtrip time. See the problem?
There are quite some provisions within autoconf to help in crosscompiling, most of the standard tests work via cache-variables that you could override in a CONFIG_SITE script. Oh well, that option is not known all too well. It does help with most of the smaller crosscompiled applications. And if you have an application with its own handmade configure-time run-tests then you need to modify them to pick up some shell-var (or better a cache-var) to make things easier for you - and allow you to create multiple config-site scripts for your various platforms that you target.
Still, there are few things missing in the autotools series to support crosscompiling for the better, in the sense to get away with it and _without_ manually checking a cache-var file. A lot can be done now but some things are still missing, and if I had only time then I'd try to write up some patches myself. However, I am also one of those who do already have proper config-site files, so why investing time on other stuff *sigh*
-- cheers, guido
Larry Doolittle wrote:
I know this subject keeps coming up. I hope my suggestions are taken as constructive (presumably for post-2.58).
I ran into one more package (GNU screen-3.9.15) where the authors used autoconf, and made no provision for cross-compiling. In fact, they use many detailed run-time tests. I was able to edit configure.in to add ACTION-IF-CROSS-COMPILING arguments (tuned to my special case) to their AC_TRY_RUN macros, and got myself on the air. Not very satisfying.
There is an implicit assumption in autoconf that people who cross-compile have no way to run the executables from within the configure script. So, no provision is made for that possibility.
In my case, and I think for an increasing number of developers, my target is a relatively full-featured Linux machine. I have a file system (NFS) shared between my development workstation and the embedded target. It's fairly trivial to build in a directory that is visible by the target (excuse me, "host"), and then on the build machine echo "$HOST_TESTDIR/conftest; echo \$?; exit" | \ socket nano4 | tail -1 to see the exit code from running conftest on the host. Normally I have that NFS directory mounted read-only by my host machine, but I could change that, so even files created by the program would become visible to configure.
If the autoconf community were interested in supporting this concept, not many changes would be needed. 1. Add a new flag, like "CROSS_RUN_SCRIPT", that defines how to run programs on the host. 2. Add new macro AC_TRY_COMMAND_HOST, that uses CROSS_RUN_SCRIPT if cross-compiling, otherwise falls back to AC_TRY_COMMAND. 3. Switch from AC_TRY_COMMAND to AC_TRY_COMMAND_HOST in all the right places. 4. Change AC_RUN_IFELSE so it only crashes if "$cross_compiling" = yes && "$CROSS_RUN_SCRIPT" = ""
Comments? If I developed, tested, and submitted a patch, would anybody look at it?
- Larry
-- -- guido http://google.de/search?q=guidod GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)
