To address "The --help output needs to be made (much) better" I'd like
to suggest that --help and -h each give the same BRIEF summary of under
24-lines of 80-column text. Additionally implement --help=[topic] to
give more info on related groups of options. Of course, -h and --help
would list the valid "topic" values in their brief output.
Just my USD 0.02
P.S. arguments is misspelled in the subject line :-)
On 4/21/2011 3: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
Paul H. Hargrove PHHargrove_at_[hidden]
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900