Yes, this is probably better.
I took a *quick* glance through the 232-line output before I sent this and probably made a bad assumption that some of them could go away.
But definitely some of the old affinity options should become deprecated. That part of the proposal still stands.
On Apr 21, 2011, at 6:52 PM, Ralph Castain wrote:
> Might help if you were to list those CLI params you believe to be removable and/or those you propose to deprecate.
> Just a quick glance: I don't see any options that are defunct, though we could argue about how many people use them. So perhaps what we discussed - having a short response for -h that lists the most commonly used ones, and a longer response to --help that contains them all - might be more appropriate?
> On Apr 21, 2011, at 9:51 AM, Jeff Squyres wrote:
>> WHAT: Deprecate a bunch of old mpirun CLI parameters, remove *most*
>> "single dash" long mpirun options, make "mpirun --help" much
>> more user friendly
>> WHY: `mpirun --help` is currently 232 lines of output. *Ouch*
>> Additionally, the Josh/Terry/Jeff affinity re-work will end up
>> creating new mpirun CLI options and deprecating the old ones.
>> WHEN: Maybe late in the 1.5 series (the new affinity stuff is
>> tentatively scheduled for late in the 1.5 series). 1.7 for
>> WHERE: Mostly in orte/tools/orterun/
>> TIMEOUT: ORNL face-to-face OMPI meeting (May 3)
>> MORE DETAILS:
>> We simply have too many options to mpirun.
>> - Some could be removed
>> - Some should be removed
>> - Some should be deprecated (but still available)
>> - The --help output needs to be made (much) better
>> The new mapping/affinity options effectively replace a bunch of the
>> old options. The old mapping/affinity options should be deprecated in
>> favor of the new stuff.
>> Additionally, there are at least a few old orterun options that are
>> either only of interest to developers and/or have an MCA parameter
>> backing them (and are fairly uncommonly used such that the MCA param
>> could be used instead).
>> Finally, we have many options that are available via both "-foo" and
>> "--foo" (mostly for hysterical raisins). In most cases, the
>> single-dash version should be removed -- per GNU conventions, long
>> names should only be available via double-dash. There are a small
>> number of single-dash options that must be retained, however, for
>> compatibility with other MPI implementations and for mpiexec options
>> specifically listed in MPI-2.2:
>> -np, -host, -hostfile, -machinefile, -wd, -wdir, -path
>> I propose:
>> 1. Remove all other single-dash long name options.
>> 2. Make all deprecated options only available if the user
>> specifies --deprecated-options on the command line (or invokes mpirun
>> via mpirun.deprecated-options).
>> --> This allows users to keep their existing scripts that use
>> deprecated options, but with a glaring signal that "hey, this
>> option you're using may disappear in a future version!"
>> 3. Revamp the --help output to show a short listing of the most common
>> options, and a note that a) the mpirun(1) man page offers much more
>> detail, and b) --help-all shows the original, exhaustive CLI option
>> Extra bonus points would be given for anyone who'd like to implement
>> an svn/hg-like "help" command, perhaps something like:
>> mpirun help machinefile
>> ...help output specifically about the machinefile option...
>> I don't have time to do this last part, but it would be a great
>> usability feature.
>> Jeff Squyres
>> For corporate legal information go to:
>> devel mailing list
> devel mailing list
For corporate legal information go to: