On Sat, Nov 01, 2003 at 01:42:24PM -0600, Bob Friesenhahn wrote:
> > > Some embedded targets do not support the notion of seperately loadable
> > > executables so the preparation stage might involve some linking of the
> > > test program into a larger image for download. Perhaps the downloaded
> > > image needs to be converted to some transfer format like s-records.
> > > The preparation stage might take care of additional functionalities
> > > such as selecting a target board, configuring terminal server ports,
> > > etc.
> >
> > I don't see a point for configure's hook to separate those
> > four functions. Yes, they may all be necessary, but let
> > the user combine them in a single script. The only thing
> > AC_TRY_COMMAND_HOST(COMMAND) cares about is the results of
> > running the program, not the subsequence of actions it takes
> > to run the program and return the results. Occam's razor
> > argues for keeping the interface between autoconf and the
> > embedded infrastructure as simple as possible.
>
> I think in this case your razor is too sharp. The failure to download
> an image to the target should not be considered to be a feature-test
> failure. Seperating the functions keeps them simple and ensures that
> any reported errors can easily be handled.
Your error-handling argument is convincing. I can imagine
where the test program accidentally grows in size (perhaps someone
changed compiler versions) and the binary becomes too big to
fit in the target memory. This error needs consequences
different from the error flags set up by the writer of the
AC_RUN_IFELSE test. Can you convince me the process needs
to be divided into more than two pieces (download + run)?
If someone turns off the target or breaks the network connection
at just the wrong time, I personally think it's acceptable
to have autoconf stall. We get into atomicity of network
operation trouble pretty fast, and that's not something
that autoconf can hope to solve. We kind of have to assume
that the environment in which autoconf runs is stable and not
half-crashed, hmm?
Guido wrote:
> After thinking it over a little, hmmm, we have some defined means to
> override some test results, what ways do we have to override the
> means to do runtime checks? I know some that override the compiler
> and flags to be used, what about test snippets in ac_run style? Isn't
> it the case that today we let stuff compile via a lot of indirections
> but the actual test run invokation is blunt right through shell exec.
> ... So, what's so hard to test-and-run-through a wrapper script
Well, that's what my idea (and successful patch) provides.
It is now officially in the "it works for me" category.
If anyone here wants to look at it, and hasn't been sent a
private copy, let me know. I'd like at least one other
person to say either "that makes sense" or "it works for
me, too" before I let it into the wild.
- Larry
