Should -help option on Windows match other platforms.

[biagas]

The launcher on windows currently has its own usage text, which is very truncated compared to other platforms.
In working on #5088, it came to my attention that the -help information used for other platforms is now stored in text files which could also be used on Windows.

So, it makes sense to modify the windows-launcher to do so, except that some of the 'visitusage.txt' (-help) doesn't apply to Windows, and much of the 'visitusageplus.txt' (-fullhelp) doesn't apply.

There are also options in the windows-usage that don't appear in either of the usage text files, probably because they need to be run through the launcher on Windows (eg no stand-alone script that calls the launcher under the covers):

-cinema
-mpeg2encode
-transition
-composite
-silex
-xml2XXX

I'm all for reducing code duplication, even usage text, but how best to handle options that don't apply for Windows?
Simply add a 'Not applicable for Windows OS' at the end of each option's description where appropriate?
Or is there a better way?

Also note, currently there is no -fullhelp option for Windows.

[markcmiller86]

We could manage the content in these usage files a bit better by having the ability to bracket lines with tags (that get removed) that allow us to filter content depending on platform. So, an un-tagged block gets spewed with -help on any platform. But, a block tagged with #ifdef win32 or something only gets spewed with -help when on Windows and a block with tag #ifndef win32 only gets spewed with NOT on Windows.

[biagas]

That could work, but requires parsing of the file, which currently just gets slurped up into a string and printed.

[markcmiller86]

To answer your lead question...no...I think help on windows should be windows-specific. That said, do you have a feel for how many users go about it with the Linux-style, command-line oriented command --help approach versus some other GUI-based approach that is more typical of the way Windows applications (and users) work? What we could do is move all the help text to a single file, bracketed with tags as proposed above (we could even use CPP approach) and then have the build generate the real content that gets spewed for that platform.

[biagas]

Most of visitusage.txt that is used for -help is applicable to Windows, so I think at the very least, Windows help can use that, with the extra commands needed for launching tools like xml2cmake and silex.
As for visit -help usage on Windows, it obviously hasn't been used very frequently: it hasn't worked for releases since we moved to creating windows-apps instead of console-apps. Plus the user must be starting VisIt from some sort of terminal or command prompt. I think this might become more common as more of our local customers are pushed into Windows for their laptop or desktop machines.

As for other forms of help usage on Windows, I can and do use it for other programs when I forget their options.

[biagas]

We agreed to annotate the current help text with preprocessor defines, and then process the file during a build to generate the actual file that will be used with --fullhelp.