[Python-Dev] HP-UX clean-up (original) (raw)

Martin v. Loewis martin at v.loewis.de
Wed Jan 7 13:00:28 EST 2004

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

More information about the Python-Dev mailing list