Re: Arguments to configure

[Sébastien Hinderer]

Dear Nick,

Many thanks for your response, I find it very helpful!

Nick Bowler (2018/10/03 14:19 -0400):
> Hello,
> 
> Responding to part of your message...
> 
> On 2018-10-03, Sébastien Hinderer <address@hidden> wrote:
> > In the same vein, I was wondering why the 'AC_SYS_INTERPRETER' macro
> > doesn't come in three variants, one for build, one for host and one for
> > target because I imagine that one may want to know whether #! is
> > supported on each of these platforms. Well perhaps not on the build
> > system, but, at least for us, that would matter for both host and
> > target.
> 
> I would imagine that it's simply impossible for configure to determine
> whether #! scripts work on anything other the build system.

Sure, but I thought it could simply be hardcoded. Although not ideal,
that would have the advantage that the info is hardcoded in only one
place from where it can be shared between all autoconf-based projects.

> So in the cross-compilation case, if your goal is to portably install
> scripts that run on the host or target system, you will presumably need
> to use a pessimistic default: that is, you must assume that #! scripts
> are not supported.  You could add an option to override this behaviour
> (typically configure scripts implement these sorts of overrides via the
> cache variable mechanism).

That's a good idea, thanks!

> POSIX demands that when any command is executed (by the shell, anyway),
> if it does not start with #! and is not recognized as an executable
> binary file then it is executed as a shell script.  So in the portable
> pessimistic default case the only kinds of scripts you can install are
> shell scripts that do not start with #!.  The same behaviour is also
> mandated in recent editions for the execvp and execlp functions (I
> imagine this was standardizing widespread practice at the time).
> 
> In practice I imagine (without proof) that something like #!/bin/sh is
> widely portable: that is implementations will either not support #! at
> all (and thus execute it as a shell script) or they will support it in
> the expected manner (also executing it as a shell script).

I see, thanks. Well I think that would not be enough for us but we can
deal with systems where #! is not supported so going with the
pessimistic default seems pretty reasonable.

Thanks again,

Sébastien.