On Tue, Sep 18, 2012 at 06:40:35AM -0700, Trent Nelson wrote:
> Side bar design question: on BSD/Linux/OSX w/ gcc/clang, if you're on
> an amd64 platform, you'll get a 64-bit build.  This isn't the case for
> Solaris, HP-UX and AIX -- the default is always 32-bit.  You need
> aforementioned gymnastics to coerce a 64-bit build.
> 
> Is this by design?  If so, then I guess I'm proposing that ./configure
> should have a `--with-64`-type argument that'll generate a 64-bit
> build.
> 
> If not, then we need to decide whether to change the default behavior
> such that ./configure always generates a 64-bit build if you're on a
> 64-bit platform -- if you want a 32-bit build, you need to explicitly
> tell ./configure (i.e. --with-32).
> 
> Changing the default is probably only viable for 3.4 onwards.  It'd be
> nice if 2.7->3.3 had generic configure support for 64-bit builds
> though (via --with-64).
> 
> XXX TODO for trent: review autoconf's offerings... getting 64-bit
> builds from vendor cc's can't be that unusual.

    Just wanted to make note of a precedent I noticed yesterday whilst
    coercing local builds of Tcl, expect and a few other things on the
    Solaris 10 SPARC box: they all use `--enable-64bit` as the arg to
    configure to enable 64-bit builds.

    Additionally, none of them default to 64-bit out-of-the-box; they
    all inherit the underlying compilers "default" behavior.  Which
    means gcc/clang gets you 64-bit on amd64, but a cc build on a
    64-bit host may not.  (I need to check a few more permutations on
    this, like what happens with gcc on SPARC/IA64 etc if the host OS
    is 64-bit -- does it default to 64-bit?)

    Side note: some of those projects had *much* nicer autoconf-fu
    than we do.  Tcl implements the --enable-64bit stuff in aclocal.m4.

    So, I'm changing my stance from what I quoted above.  We should try
    mimic the precedent set by other projects:

        - Use --enable-64bit as the flag.
        - "Default" 64-bit builds depend on the underlying compiler.