On Sun, 2 Nov 2003, Larry Doolittle wrote: > > > > 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)? Certainly it is a necessity to support cleaning up after the test. It is normal for configure to remove test executables. That is at least a third required step. > 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? Whenever more than one computer is involved, it is quite possible/likely that the environment will be half-crashed. If the environment is half-crashed, configure should notice it and exit rather than producing bad test results. Bob ====================================== Bob Friesenhahn bfriesen@xxxxxxxxxxxxxxxxxxx http://www.simplesystems.org/users/bfriesen
