Re: cross-compiling philosophy

[Larry Doolittle]

> > 1. Add a new flag, like "CROSS_RUN_SCRIPT", that
> >    defines how to run programs on the host.
> 
> Should the maintainer be required to define the cross-run script?
> I'd think that often this would be up to the installer.  So, shouldn't
> "configure" have an option to specify the cross-run script?  E.g.,
> "configure --cross-run=/my/platform/target/run-on-target".

You're right, this has nothing to do with the package maintainer,
and everything to do with the build/test environment.
I guess I didn't describe it very well.  We will have to
document the syntax of this command/script.  One argument,
which is a shell command to run on the target?  The file
system context has to be the same (mirror or copy) as that
of the configure script?  I will provide an example that
"works for me".

> > 2. Add new macro AC_TRY_COMMAND_HOST, that uses
> >    CROSS_RUN_SCRIPT if cross-compiling, otherwise
> >    falls back to AC_TRY_COMMAND.
> 
> Shouldn't AC_TRY_COMMAND do this?  I'd think it'd be the normal case.
> 
> That is, I would expect AC_TRY_COMMAND to be equivalent to
> AC_TRY_COMMAND_HOST.  We will need a new macro AC_TRY_COMMAND_BUILD
> that runs on the build system (useful for deducing things about which
> compiler we're using, say) but normally people are interested in
> trying to run the package, not to run tools used to build the package.

I guess I'd have to look more carefully at places where
AC_TRY_COMMAND is used, to decide which is the less invasive
change.  Let's see.  In c.m4, one case obviously run on the
build system.  In lang.m4, one case described as FIXME that
figures out whether to add EXEEXT.

In general.m4, one use in _AC_RUN_IFELSE that clearly has to
run on the host/target, two uses in _AC_COMPILE_IFELSE and two
uses in _AC_LINK_IFELSE that I don't fully understand, but
look pretty safe to run on the build machine.

       - Larry