On Fri, Oct 9, 2020 at 6:35 AM <wferi@xxxxxxx> wrote: > Nick Bowler <nbowler@xxxxxxxxxx> writes: > > On 2020-08-23, wferi@xxxxxxx <wferi@xxxxxxx> wrote: > >> The documentation linked above is confusing because it describes the > >> 2.13 behavior, the 2.50 behavior and the "backward compatibility > >> scheme" together. For example it starts with "the chain of default is > >> now simply: target defaults to host, host to build, and build to the > >> result of config.guess", then later "when --host is specified but > >> --build isn't, the build system is assumed to be the same as --host", > >> which is a contradiction, although "eventually, this historically > >> incorrect behavior will go away." So has this eventuality happened > >> already? > > > > I think either the statement about the build system type being set > > to the --host value is just wrong or that the eventuality must have > > happened almost immediately (certainly build_alias does not appear > > to get set to anything at all if --build is unspecified, contrary to > > what the manual suggests). I think this is referring to the behavior of the AC_CANONICAL_* macros. Both AC_CANONICAL_BUILD and AC_CANONICAL_HOST set their respective variables from the output of config.guess if they're not already set. This is *not* the same as setting $build_alias to whatever $host_alias happens to be if it's not already set. (Just to add another layer of confusion, eh?) You're not supposed to look at any of the $build, $host, or $target variables without running the respective AC_CANONICAL_* macro first, so the manual's not _completely_ wrong. > > The behaviour today is essentially unchanged since the Autoconf 2.50 > > release almost 2 decades ago. > > > > It's quite possible you are the first person to read this section of > > the manual in all that time and actually say "hey wait a minute..." > > Thanks much for your detailed answers and explanations! I noticed that > the 2.70 release is being planned, so I recommend to fold all this very > useful information into the cross-compilation section of the manual and > to drop the out-of-date sentences before the new release is finalized to > let your efforts reach wider audience. I'm adding "revise this manual section" to my todo list, but I wonder whether it might make sense to change autoconf's behavior as well. I remember when the "backward compatibility scheme" was introduced, it was not intended to last for nearly as long as it has, and I've seen people get tripped up by the fact that $cross_compiling can be initially set to a value other than "yes" or "no" and then change when you invoke AC_PROG_CC. Specifically, I'm thinking of removing the "FIXME: To remove some day" code at the end of _AC_INIT_PARSE_ARGS that can set $cross_compiling to "maybe", and the corresponding code in _AC_COMPILER_EXEEXT_CROSS. The new behavior would be that if you specify --host=<anything> and don't also say --build=<same anything>, cross compilation mode is engaged. The AC_CANONICAL_* macros would not be changed. It's been a long time since I did anything involving cross compilers, so I'd like to hear from people who do regularly cross-compile things before I make any such change? zw
