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
