On Thu, Oct 30, 2003 at 01:24:59AM -0600, Bob Friesenhahn wrote:
>
> There are an infinite number of ways to run executables on a target.
> How is configure to know how to run executables on a target?
As I imagined, and Paul Eggert made explicit, by the person configuring
the system typing
configure --cross-run=/my/platform/target/run-on-target
> Your example of a Unix-like system with NFS mounts to the build
> system is the most trivial case.
I agree. I like trivial cases. They're the easiest to make work. ;-)
> One possiblity that comes to mind is to use DejaGNU as the framework
> to execute the program on the target and require the user to write the
> code to download the exectuable to the target and run it. The user
> would be responsible for writing the bit of Tcl code required to
> interface to the target.
I have never used DejaGNU. I think a lot of embedded development
systems can download executables and run them, one way or another.
> I don't see any reason to assume that the target supports a filesystem
> at all. Perhaps the exectable needs to be downloaded to the target
> somehow (maybe even over a serial port!) and told to execute.
That's true. Tests that simply provide a return code from the
return from main() would work for the largest subset of targets.
Unfortunately, application writers also resort to passing
information back in a file. The serial port possibility is real;
in that case, this approach would decrease the needed effort by
the programmer and increase accuracy, at the expense of more wall
clock time. But it doesn't attempt to set policy: the user is
free to go back to the old way, by not providing --cross-run=
at the invocation of configure.
Here's a list of the AC_TRY_RUN tests from my example, screen-3.9.15:
fifo usable - return code only
broken fifo - return code only
sockets usable - return code only
unix domain sockets - return code only
can select count - return code only
termcap/terminfo - return code only
tty permissions/group - string written to conftest_grp file
avenrun symbol - return code only
signal implementation - return code only
memcpy works - return code only
memmove works - return code only
bcopy works - return code only
Executive summary: full of cruft, but most of the benefits of
cross-target running come from just providing the return code.
Ralf Corsepius added:
> Let me add that there also exists an infinite number of targets where no
> possibility exists to run executables as part of autoconf checks.
And my suggestion is useless for those people. They have to
research their systems behavior the hard way, and cope by hand
with application authors who don't code ACTION-IF-CROSS-COMPILING
into their autoconf scripts.
> Even if you can manage to get this working, this only helps in cases
> where you have physical access to a target.
>
> In cross-compilation situations however, you often work off-line,
> without any physical access to the target hardware.
I hope I'm never in that situation. Even if it takes special debug
hardware, I want my target on-line enough that I can run regression
tests. If it's on-line enough for that purpose, it's probably also
on-line enough for autoconf.
I never presented this as a panacea, only a way to extend the autoconf
philosophy of "test the features instead of guessing" to include more
pairs of (tests, cross-compiled targets). The nice thing is that
(guessing here) it will be backwards compatible with most existing
application's config.in files.
Enough talk. I'll start trying to make these ideas work in my lab.
Is autoconf-2.57g a reasonable base, or do I need to start from CVS?
- Larry
