RetroSearch Browse

Fri Jan 9 10:44:44 EST 2004 · https://mail.python.org/pipermail/python-dev/2004-January/041847.html

>------------------- Message from 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
>--------------------------------------------------------

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-January/041847.html below:

[Python-Dev] HP-UX clean-up