Re: Supporting AC_TRY_RUN for cross-compilation (was: AC_FUNC_SETVBUF _REVERSED in cross-compilation)

[Paul Smith]

%% Dan Kegel <address@hidden> writes:

  dk> Paul D. Smith wrote:
  >> AC_FUNC_SETVBUF_REVERSED macro has no option for how
  >> it behaves during cross-compilation.
  >> ...
  >> Anyone else have any good ideas?

  dk> Yes, we need to fix all the macros and config scripts that 
  dk> use AC_TRY_RUN to behave better, but that's a big job,
  dk> and even when we're done, we'll end up either requiring
  dk> users to override tests via the environment OR we'll have
  dk> defaults which are broken for some platforms.

For some kinds of things you can take "conservative" approaches that
work on all systems (for example, for vfork() you can say you don't have
one (just an example, I don't think vfork uses AC_TRY_RUN)).

But, you're right, for some things (like AC_FUNC_SETVBUF_REVERSED) there
is no conservative approach that works on all systems... except not
using setvbuf() at all of course.

  dk> How about this: configure should take a commandline argument,
  dk> --with-remote-run=, which specifies a wrapper command
  dk> which knows how to execute tests remotely.  For instance, 
  dk> --with-remote-run="ssh chassis" would use ssh to run the AC_TRY_RUN
  dk> test on machine 'chassis'.  If --with-remote-run is not
  dk> specified, AC_TRY_RUN would behave just as it does today.

I guess my response to that is, is it realistic to think that you have a
platform for which you can't natively compile and need to cross compile,
and yet it supports ssh (or rsh or whatever)?  Not only must they
support ssh/rsh, but they have to be able to NFS-mount your working
directory, or have some other method of putting the test program down on
the target host.

I know on the kinds of systems I need to cross-compile for (embedded
systems) there's no good way to invoke a program remotely.  I guess I
would expect that this would be the case more often than not in a
cross-compiling environment.

Or, put another way, I'm not sure such a thing would be useful enough to
justify the work involved, both implementing it and also supporting it.


I guess I'd prefer something simpler, which is just a conservative
response for macros where that makes sense, and some kind of common
behavior for macros where there is no useful conservative response that
works everywhere.

That common behavior might be a special token that lets the maintainer
know that they need to treat this in a special way: either leave out
some functionality or fail the configure or whatever.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden> HASMAT--HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.