openmpi.spec: fix configure external 3rd-party package conflict

[wenduwan]

When the user provides both --with-<package>=/path/to/local/install and all_external_3rd_party=1(which is the default value), the latter overrides --with-<package>=external. In this case the former explicitly provided options should be followed instead.

[bwbarrett]

This seems like the wrong fix. All you've done is make the configure line ./configure --with-<foo>=external --with-<foo>=<path> and assume that configure will take the last option. That's likely to always be true, but a better option seems to be handling this way earlier in the process, by being selective about how the --with-<foo>=external flags are added.

[wenduwan]

In the update we inspect user provided configure_options and only set --with-<pkg>=external if:

• all_external_3rd_party is true
• user did not specify --with-<pkg>=<path> at all

I was looking for a better place to put this logic but landed here right before configure ..., since that is the only consumer of those options.

[jsquyres]

If we detect --with-<package>=blah and all_external_3rd_party=1, why don't we just abort? We've been given conflicting requirements, after all -- it seems like there will not be a correct answer for all situations. Let the human figure it out, and re-run with non-conflicting options.

[wenduwan]

@jsquyres That should also work. Right now all_external_3rd_party=1 is the default, so in the suggested approach the user has to set all_external_3rd_party=0 to override --with-pmix=/path/to/local/install - I wonder what should the spec file set for the others, e.g. --with-prrte, etc. I think the most sensible decision in this case would be:

• If the user set all_external_3rd_party=1 then all of the packages will be --with-<pkg>=external. The user should not set any of the --with-<pkg>.
• If the user set all_external_3rd_party=0 then all of the packages MUST be set explicitly.

In other words it would be all-or-nothing. I'm not sure how much churn this will cause for the packagers in the field using the current spec file, but at least now we don't have the ambiguity anymore.