On Thu, Dec 13, 2012 at 10:28:00PM -0800, Ned Deily wrote:
> 
> Ned Deily added the comment:
> 
> Without having reviewed the proposed change in detail, a couple of
> comments.  On current OS X systems and others, the compiler could be
> clang which perhaps should be treated as gcc for most autoconf
> purposes.

    I'm not intending to target OS X in the autoconf block I referred
    to; it's a popular platform for developers and users, and doesn't
    have any of the problems that the proprietary *NIXes/compilers
    have.

    This work is solely aimed at Solaris, Tru64, HP-UX, AIX and IRIX.

> Also, why are we putting any effort into supporting IRIX
> anymore?

    We?  It's just me :-)  So a more appropriate question might be why
    am I bothering to put effort into supporting it?  And the answer to
    that is simply because I can; Snakebite has an SGI Origin running
    the latest version of IRIX with the MIPSpro compiler suite, which
    is all the hardware I need to keep things chugging along.  (IRIX
    also has a huge active "fan" base of users that run a lot of OSS
    software -- nekoware et al.)

> Both IRIX and the MIPS processor lines it runs on was retired by SGI
> in 2007.  That's why support for IRIX was pulled from Python 3.

    Support was pulled for, to quote PEP 11, "IRIX 4 and --with-sgi-dl";

    PEP 11 also has a nice clause that basically says platform support
    is primarily based on having an active maintainer willing to keep
    everything in shape -- I'm happy to be marked as the maintainer for
    all the aforementioned *NIX platforms.

    Martin made a good point a few weeks ago when we discussed this on
    infrastructure@; his concern was the effort involved in supporting
    additional platforms could detract developers from more important
    tasks.

    I agree -- they're esoteric platforms at best, EOL at worst, and
    just because I'm maintaining them shouldn't mean other developers
    have to worry about breaking them.  They're not anywhere near as
    important as the big 3 (Linux/Windows/OSX).  If they do break,
    though, I'll keep fixing them as long as I'm actively maintaining
    support for that platform.

    The motivation behind this particular change is simple: it took
    about three days to nail down the exact flags to use on Solaris
    SPARC 32-bit to get a working ./python (with lots of referring
    to various Sun/Oracle compiler docs).  No-one else should have
    to go through this much effort -- ./configure should pick the
    right flags out of the box for the following permutations:

    32/64 bit debug builds:
        ./configure --without-gcc --with-pydebug
        ./configure --without-gcc --with-pydebug --enable-64bit

    32/64 bit release builds:
        ./configure --without-gcc
        ./configure --without-gcc --enable-64bit

    (And again, just to clarify, none of this work will remotely
     affect Linux, OS X or the *BSDs.  It doesn't take three days
     of reading compiler manuals to get working builds on those
     platforms.)