Re: Proposed patch for ax_enable_builddir.m4

[Guido Draheim]

Julian Cummings schrieb:
> Attached is a proposed patch for the autoconf macro ax_enable_builddir.m4.
> The patch universally replaces "host" with "build" and "HOST" with "BUILD".
> The rationale is that typically the user wishes to segregate builds based
> upon the BUILD target rather than the configuration HOST type.  Now that
> these host and build variables are treated as more fully distinct in
> autoconf, it makes sense to honor this disticntion.  I notice that you
> created a separate macro ax_enable_builddir_uname.m4 that sort of does the
> same thing, except that it explicitly uses the command "uname -msr" instead
> of relying on the existing autoconf macro AC_CANONICAL_BUILD.  I don't see
> the point of this.  (Also, this "uname" macro omits support for transferring
> the config auxiliary directory $ac_aux_dir for some reason.)  Perhaps with
> my proposed patch, the ax_enable_builddir_uname.m4 macro becomes
> obsolete...?  Please let me know your thoughts.
>
> Regards, Julian C.
>
> Dr. Julian C. Cummings
> Staff Scientist, CACR/Caltech
> (626) 395-2543
> address@hidden
>

Sorry, Julian, but that's completely wrong from my POV. The macro had been
invented in a build environment using crosscompilers - there is a compile
BUILD host that targets the compiled binary for a runtime HOST. The GCC
derived canonical system defines have an additional TARGET that implies
the compiled runtime binary to be a compiler compiling for third host
type.

On such a crosscompiler build host it is very natural to install multiple
compilers which have a name prefix defaulting to the runtime $HOST. Now
have a look at /usr/share/autoconf/autoconf/c.m4 AC_PROG_CC and its use
of $ac_tool_prefix which you find again in autoconf/general.m4 set to
test -n "$host_alias" && ac_tool_prefix=$host_alias-

Now that's where the differentiation comes from for different build
subdirectories that are meant to be used for different build environments.
Of course, I was using the macro also for other projects where one would
not use a crosscompiler but instead one would remote login to different
system host and using the native compiler ($build == $host) in a
/home directory mounted from a central place. That was the case for
the sourceforge compilefarm (RIP) atleast and I guess it is a common
scenario for other multi-target development labs.

So, it is really the runtime $HOST that I like to distinguish and for
remote login with a native compiler (compiling for its own host type)
it is equal to the $build defines.

The _UNAME variant has a different reason however. The original macro
was used in a build environment where a wrapper script was already
presetting the runtime target host via a some shell variables. And it
was using the naming scheme of the config.sub parts. During later
developments I was noticing it to be somewhat cumbersome on two
accounts
(1) in most environments there is no shellvariable $HOST predefined
    and there were problems to execute the config.guess shell-script
    (mainly because I moved it to a subdirectory and different
    automake/autoconf version were shuffling variables around how to
    find the path to it)
(2) the config.guess is distinguishing less host types as it usually
    strips of versions and vendor specifics. That is especially true
    for the load of Linux distros which is generally put under the
    common name of i686-suse-linux-gnu. In the sourceforge compilefarm
    it could not distinguish between suse, redhat, debian, etc but
    uname -msr can give us atleast sligthly different kernel versions.

So effectivly, the uname -msr is easier to handle - I can easily run
a custom make (make HOST=`uname -msr`) to target a different runtime
host in a crosscompiler environment and secondly it allows me to
easier get away with a compilefarm layout where multiple compile
hosts are mounting the same home directory for the build sources.

cheers, Guido
(CC'd to autoconf ML for broader reference - ac-archive ML being dead)