Some comments on program_options/howto.html
I dutifully followed the link from the --no-foo thread, and I have some comments. The Winmain Command Line section says split_command_line in the text, split_winmain in the example code. The Response Files section shows example code for parsing a response file using Tokenizer. Why shouldn't one be able to use split_command_line instead? There doesn't seem to be any difference between a command line in string format and a response file. Also, response file support doesn't seem proper. Response files should work like this: @file1 --option=value @file2 If file1 contains --option, it will be overriden by the command line. Similarly, all options in file2 will override both file1 and the command line --option=value. From a cursory look at the example, this doesn't seem to be the case, but I may be wrong. An additional parser could have been used to enable this behavior if it were possible to return more than one option/value pair from it. (This would also allow "option bundles" like -O1 expanding into a set of option/values.)
Hi Peter,
I dutifully followed the link from the --no-foo thread, and I have some comments.
The Winmain Command Line section says split_command_line in the text, split_winmain in the example code.
The text is wrong and example is right, the function is called "split_winmain". I'll fix the typo right now.
The Response Files section shows example code for parsing a response file using Tokenizer. Why shouldn't one be able to use split_command_line instead? There doesn't seem to be any difference between a command line in string format and a response file.
Good question. The problem is that split_winmain uses Windows-style quoting rules, while tokenizer uses more Unix-like rules. I'm not sure which syntax the response files should use.
Also, response file support doesn't seem proper. Response files should work like this:
@file1 --option=value @file2
If file1 contains --option, it will be overriden by the command line. Similarly, all options in file2 will override both file1 and the command line --option=value. From a cursory look at the example, this doesn't seem to be the case, but I may be wrong.
The behaviour of the example is that command line will override anything specified in response files. If that behaviour is not correct for Windows, I'd need to modify the example a bit -- by iterating over vector of options which is returned by parse_command_line, and replacing @ options will those from response file.
An additional parser could have been used to enable this behavior if it were possible to return more than one option/value pair from it. (This would also allow "option bundles" like -O1 expanding into a set of option/values.)
In fact, I plan to make additional parser return vector<option>. Of course, this will be done only after release. - Volodya
Hi Peter,
I dutifully followed the link from the --no-foo thread, and I have some comments.
The Winmain Command Line section says split_command_line in the text, split_winmain in the example code.
The text is wrong and example is right, the function is called "split_winmain". I'll fix the typo right now.
The Response Files section shows example code for parsing a response file using Tokenizer. Why shouldn't one be able to use split_command_line instead? There doesn't seem to be any difference between a command line in string format and a response file.
Good question. The problem is that split_winmain uses Windows-style quoting rules, while tokenizer uses more Unix-like rules. I'm not sure which syntax the response files should use.
Also, response file support doesn't seem proper. Response files should work like this:
@file1 --option=value @file2
If file1 contains --option, it will be overriden by the command line. Similarly, all options in file2 will override both file1 and the command line --option=value. From a cursory look at the example, this doesn't seem to be the case, but I may be wrong.
In the example, options on the command line will override options in both response files. If that behaviour is not correct, I'll have to modify the example by looking over vector of parsed options that's returned by parse_command_line and expanding @ options. Do you think that specifying the same option in @file1 and @file2 is OK, and definition in @file2 should override the previous one? On the command line, two duplicated assignments to a scalar option results in an error.
An additional parser could have been used to enable this behavior if it were possible to return more than one option/value pair from it. (This would also allow "option bundles" like -O1 expanding into a set of option/values.)
I plan to make additional parser return vector<option>. But that's after release. - Volodya
Vladimir Prus wrote:
The Response Files section shows example code for parsing a response file using Tokenizer. Why shouldn't one be able to use split_command_line instead? There doesn't seem to be any difference between a command line in string format and a response file.
Good question. The problem is that split_winmain uses Windows-style quoting rules, while tokenizer uses more Unix-like rules. I'm not sure which syntax the response files should use.
My instinctive reaction is to provide both via an options argument to split_command_line (a name that would now be more appropriate). But I haven't devoted much time to thinking this through, so I may be wrong. :-) In any event, the tokenization isn't much fun. I'd expect the library to provide a convenient mechanism for parsing a response file.
Also, response file support doesn't seem proper. Response files should work like this:
@file1 --option=value @file2
If file1 contains --option, it will be overriden by the command line. Similarly, all options in file2 will override both file1 and the command line --option=value. From a cursory look at the example, this doesn't seem to be the case, but I may be wrong.
In the example, options on the command line will override options in both response files. If that behaviour is not correct, I'll have to modify the example by looking over vector of parsed options that's returned by parse_command_line and expanding @ options. Do you think that specifying the same option in @file1 and @file2 is OK, and definition in @file2 should override the previous one? On the command line, two duplicated assignments to a scalar option results in an error.
It should certainly be possible to override @file1 from the command line and from @file2 - this has many valid uses. However I'm not sure about overriding the command line from a subsequent response file (@file2). This probably needs to be flagged as an error, because it's usually not what the user needs.
Peter Dimov wrote:
Vladimir Prus wrote:
The Response Files section shows example code for parsing a response file using Tokenizer. Why shouldn't one be able to use split_command_line instead? There doesn't seem to be any difference between a command line in string format and a response file.
Good question. The problem is that split_winmain uses Windows-style quoting rules, while tokenizer uses more Unix-like rules. I'm not sure which syntax the response files should use.
My instinctive reaction is to provide both via an options argument to split_command_line (a name that would now be more appropriate). But I haven't devoted much time to thinking this through, so I may be wrong. :-)
In any event, the tokenization isn't much fun. I'd expect the library to provide a convenient mechanism for parsing a response file.
Noted.
Also, response file support doesn't seem proper. Response files should work like this:
@file1 --option=value @file2
If file1 contains --option, it will be overriden by the command line. Similarly, all options in file2 will override both file1 and the command line --option=value. From a cursory look at the example, this doesn't seem to be the case, but I may be wrong.
In the example, options on the command line will override options in both response files. If that behaviour is not correct, I'll have to modify the example by looking over vector of parsed options that's returned by parse_command_line and expanding @ options. Do you think that specifying the same option in @file1 and @file2 is OK, and definition in @file2 should override the previous one? On the command line, two duplicated assignments to a scalar option results in an error.
It should certainly be possible to override @file1 from the command line and from @file2 - this has many valid uses.
Could you explain the uses for overriding @file1 from @file2? - Volodya
Vladimir Prus wrote:
Peter Dimov wrote:
It should certainly be possible to override @file1 from the command line and from @file2 - this has many valid uses.
Could you explain the uses for overriding @file1 from @file2?
A typical use case would be when you have @common that contains the most 'common' options and @specific that adds and overrides some - N+M response files instead of N*M. Option inheritance. :-)
participants (2)
-
Peter Dimov -
Vladimir Prus