Trent Nelson added the comment:
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.)
----------
title: Improve ./configure's support for 32/64-bit debug|release|profiled
builds w/ vendor (non-gcc) compilers on proprietary UNIX systems
(Solaris/HP-UX/AIX et al). -> Improve ./configure's support for 32/64-bit
debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary
UNIX systems (Solaris/HP-UX/AIX et al).
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15963>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
