[Python-Dev] HP-UX clean-up

[Martin v. Loewis]

Nick Monyatovsky wrote:
> Would not it be better if you let the users (people who compile Python) decide
> what they want?

No, not at all. configure should always give a working installation if
invoked without options. If we have to make decisions for people to
obtain such a working installation - fine. We then have to ask whether
people might have made different decisions, and whether we want to
support them in that decision. In many cases, we found that not
giving choices is the right thing.

So, for your set of options:
1. configure should find out automatically how to enable large
    file support on a 32-bit machine. In fact, there is code in
    configure.in to automatically detect LFS. I'm surprised that
    you are specifying LFS on the command line - this should
    not be necessary.

2. Assuming -Wl,+s -Wl,+k are warnings: We would turn them on
    if they are always acceptable, and leave them off if there
    are cases were they are not applicable. Figuring out whether
    warning options are needed/possible is too much effort,
    letting the user make the choice is pointless - our other
    compilers give plenty of warnings, so I believe that the
    HP compiler's complaints are likely false positives or
    otherwise irrelevant.

3. We would compile/link with threads always if possible,
    unless --disable-threads was given. If compiled with threads,
    configure should know to pass -lpthread.

4. On the model selection options, I don't quite understand
    why you say that this set of options gives portable binaries.
    I would have thought that +DA1.1 +DS2.0 is the set of option
    that gives portable binaries. Of course, if we can assume
    all hardware is PA 2.0 meanwhile, this would be fine. In
    that case, we would always add the PA 2.0 option set,
    leaving the user no choice.

>    1) It is hard (== unreliable) to try to distinguish them using 'model',
> etc.;

Then there should be no choice at all.

>    2) Reliance on such techniques will inevitably break overtime when the new
> processor denominations come into play;

Then there should be as few options as possible, assuming that the
compiler defaults will do the right thing, anyway (which appears
to be the case with respect to model selection).

>    3) Most importantly, it is possible to be on the 64-bit machine and be
> purposefully compiling for a 32-bit processor (to cover the broadest customer
> base). It is also possible to be on RISC and compile for ITANIUM and vice
> versa, because it is the same compiler. Moreover, ITANIUM machines will run
> RISC binaries.

I don't think it should be directly supported. By default, configure
should force PA binaries on PA hardware, and Itanium binaries on Itanium
hardware.

One issue is whether we should produce 32-bit or 64-bit binaries on
PA 2.0 machines by default; I don't know which one is more reasonable.
Switching to the other one should be as simple as setting CC before
invoking configure (this is how it works on Solaris).

>    People, on the other hand, usually know what machine they are working on
> now, and what machine they want Python to work on after they built it.

People should be able to specify things that they reasonably should
be able to specify. If they don't specify anything, something reasonable
should still happen.

> Maybe there should also be some sort of option for expects who will not want
> Python to be compiled for generic processor; who might purposefully want to
> compile Python on their particular hardware and have it fully optimized for it
> to gain maximum performance.

No, no, no. If you want to highly tune your build, you are expected to
edit the makefile. Providing an explicit option for that will place
a burden on users who are not able to answer difficult build questions
(and, trust me, this is the majority of the users).

Regards,
Martin