[Python-Dev] HP-UX clean-up
mon at abaqus.com
Fri Jan 9 10:44:44 EST 2004
>------------------- Message from Martin v. Loewis --------------------
> Nick Monyatovsky wrote:
> > Would not it be better if you let the users (people who compile Python)
> > 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
> > 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
> > 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
> > 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
> 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
> > 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
> > Python to be compiled for generic processor; who might purposefully want
> > compile Python on their particular hardware and have it fully optimized
> > 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).
Those are all correct observations: we are using an older (2.0) version of
Python, and had to add large file support and threads explicitly.
I will answer the architectures issue in another message, where people brought
more details of this to the surface.
Thank you, -- Nick Monyatovsky -- mon at abaqus.com
More information about the Python-Dev