[Python-Dev] HP-UX clean-up

[Martin v. Loewis]

Cameron Laird wrote:

> Clearly.  I want to take this opportunity, though, to understand
> attitude-intent-design, so that any patches in which I'm involved
> will not merely imitate what (perhaps mistakenly) exists, but will
> promote long-term usability and maintainability.   So:  when Mr.
> MacKeith describes his situation, do those with the most configure
> expertise regard it as a platform-specific instance of a cross-
> platform condition, or ... well, I just think there's a lot more
> to know to get configure.in right.

First, ask what the intent is, then evaluate the intent,
then ask for the mechanism to achieve this intent.

Intent: Generate binaries that work on all processors
Evaluation: Sounds like a good idea
Mechanism to achieve: He said
"We therefore have to have flags that will force HP to compile
for some common generic processor."
So apparently, he proposes to use compiler flags, which probably
means "command line arguments".

Then, go in cycles:

Intent: Add new command line options
Evaluation: Pro: resulting binary will get more portable
   Con: resulting binary might lose speed
     - might make this customizable
   Con: Long lists of command line options are unmaintainable
     - should reduce list to the absolute minimum to achieve
       intent
   Con: options are clearly compiler-specific
     - need to determine options depending on platform/compiler
Mechanism to achieve:
   Must use configure to select options depending on compiler
   and platform.

There is nothing we can do about the long list of compiler
options, except for documenting each one so we later know
what option was added for what reason.

This leaves the potential loss of speed.

Intent: Make cross-platform executables a user option
Evaluation: Pro: User can make a choice.
   Con: User can make a choice, anyway, by explicitly
        setting all options
   Con: User has to know about option
   Con: Option needs to be documented and maintained.

Given that making an option specifically for that purpose
adds no value and gives only problems, this intent should
not be achieved.

> Uh-oh; I just realized there's another possibility.  Maybe we're
> all more-or-less equally expert with the Python build process,
> because all that anyone does is local imitation, without aspira-
> tion to a higher design.  If so, that's no criticism of any one;
> it would reflect well on Python's robustness that it hasn't needed
> more deliberation or structure.

You are certainly wrong here. Some of us do care about the build
process, and want to have it work reliable and maintainable, and
improve on reliability and maintainability.

I personally have a very clear view of what changes I would like
to see for what reason; in particular, I strongly dislike changes
that are based on imitation. Instead, each change should be
accompanied with a rationale, and with documentation.

For example, adding new command line options to the build process is
rarely a good thing, IMO, because users don't want to specify endless
lists of command line options. They want the defaults to get it
all right the first time.

Likewise, I despise attempts to throw away the build process and
replace it with something new: anybody attempting should first
prove that the new solution is indeed capable of providing
advantages over the current process.

Regards,
Martin