<html>
<head></head>
<body>
<p>Hi Daniel,</p>
<p>Just in the moment you replied my message, I was rewriting it as I hadn't noticed it hadn't a correct format. Sorry for that and thanks for answering it anyway.</p>
<blockquote class="replyBlock" style="border-left: 2px solid #000083; margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><p>./prog <option1> | ( <option2> --arg1 --arg2) | ( <option3> --arg1 )</p>
</blockquote><p>Yes, that is exactly what I need. It's a pity commandLine doesn't implement that possibility. So I will do what you tell, parsing the arguments by myself and extending the help like you propose.</p>
<blockquote class="replyBlock" style="border-left: 2px solid #000083; margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br/>
<p>I don't see why you should really care about the order, i.e. this is<br/>
probably okay.</p>
<p>./prog --arg1 <option1></p>
<p>So why not make every argument optional (i.e. no positional arguments)</p>
</blockquote><p>The order is important in our case because I would like not to force the user to use the "-" prefix. In our tool, we have a order established in the input of arguments (these arguments are associated with the first option given). So I will simply process the arguments directly, I think. </p>
<p>Thanks for everything,</p>
<p>Pedro.</p>
<br/>
<br/>
<br/>
<br/>
<br/>
<div><em>El dia 08 may 2013 13:56, Daniel Liew <daniel.liew@imperial.ac.uk> escribió:</em></div><blockquote class="replyBlock" style="border-left: 2px solid #000083; margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><p>Hi,</p>
<p>Please try and format your e-mails better. Your e-mail is incredibly<br/>
hard to read due to its lack of new lines.</p>
<p>I don't think the designer of the CommandLine library ever intended for<br/>
cl::Positional to be used with cl::opt<T> where T is an enum.</p>
<p>e.g.</p>
<p>enum OptLevel {<br/>
g, O1, O2, O3<br/>
};</p>
<p>cl::opt<OptLevel> OptimizationLevel(cl::desc("Choose optimization level:"),<br/>
cl::values(<br/>
clEnumVal(g , "No optimizations, enable debugging"),<br/>
clEnumVal(O1, "Enable trivial optimizations"),<br/>
clEnumVal(O2, "Enable default optimizations"),<br/>
clEnumVal(O3, "Enable expensive optimizations"),<br/>
clEnumValEnd),<br/>
cl::Positional<br/>
);</p>
<p>int<br/>
main (int argc, char ** argv)<br/>
{<br/>
cl::ParseCommandLineOptions(argc, argv);</p>
<p>// Easy access in gdb (getValue is inlined!)<br/>
OptLevel* test = &(OptimizationLevel.getValue() );<br/>
}</p>
<p>It also doesn't make a huge amount of sense (based on the output of<br/>
-help) either because the OptimizationLevel options have the "-" prefix<br/>
which is almost always taken to mean that it is optional and NOT<br/>
positional. -help shows...</p>
<p>Choose optimization level:<br/>
-g - No optimizations, enable debugging<br/>
-O1 - Enable trivial optimizations<br/>
-O2 - Enable default optimizations<br/>
-O3 - Enable expensive optimizations</p>
<p>Trying</p>
<p>$ ./program -O1<br/>
$ ./program O1<br/>
$ ./program -- -O1<br/>
$ ./program -- O1</p>
<p>does not result in OptimizationLevel being modified by calling<br/>
ParseCommandLineOptions (I tested this in gdb).</p>
<p>This behaviour is arguably a bug. You're welcome to try and fix it.</p>
<p>I would like to suggest an alternative though. If I understand you<br/>
correctly you're looking for your command line syntax to be something<br/>
like...</p>
<p>./prog <option1> | ( <option2> --arg1 --arg2) | ( <option3> --arg1 )</p>
<p>I don't see why you should really care about the order, i.e. this is<br/>
probably okay.</p>
<p>./prog --arg1 <option1></p>
<p>So why not make every argument optional (i.e. no positional arguments)</p>
<p>then after calling ParseCommandLineOptions you can check the user has<br/>
used the right options by doing something like...</p>
<p>// Note cl::opt<T> is a type of Option<br/>
Option* NOTValidForOption1[] = { &arg1, &arg2};<br/>
Option* NOTValidForOption3[] = { &arg2 };</p>
<p>switch(YourOption)<br/>
{<br/>
case Option1:<br/>
for(int I=0; I < sizeof(NOTValidForOption1)/sizeof(Option*);++I)<br/>
{<br/>
if(NotValidForOption1[I]->getNumOccurrences() != 0)<br/>
{<br/>
//Fail<br/>
}<br/>
}<br/>
break;</p>
<p>case Option2:<br/>
break;</p>
<p>case Option3:<br/>
// similar to Option1<br/>
}</p>
<p>^ Note the above certainly code be coded better, this is just to give<br/>
you an idea.</p>
<p>You could also make it more obvious in the output of -help that only<br/>
certain options should be used with each other by putting them into<br/>
categories (see cl::cat() in documentation). Note this will only work<br/>
for you if arguments are mutually exclusive as an option may only be in<br/>
one category.</p>
<p>Hope that helps.</p>
<p>Dan.</p>
<p>On 07/05/13 08:58, Pedro Delgado Perez wrote:</p>
<blockquote class="replyBlock" style="border-left: 2px solid #000083; margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><p>Hi,I've been trying to code through CommandLine the options I want my tool accepts, but I find quite impossible to achieve robustly what I need .Look, I want the tool accepts a list of arguments in a particular order. For this goal, I know the cl::Positional flag. But, the problem is that *the first argument must be one of a set of options *(like a kind of subcommand of the tool). In my case, only the three next commands are possible:</p>
<p>myTool option1myTool option2 arg1 arg2 myTool option3 arg1and I don't want a different order is possible, for instance, this is not permitted:myTool arg2 option2 arg1So, I thought about using an enum for this first argument:enum OptLevel{option1, option2, option3};cl::opt<OptLevel> OptionsLevel(cl::Positional, cl::desc("Choose one of these options:"),cl::values(clEnumVal(option1, "..."),clEnumVal(option2, "..."),clEnumVal(option3, "..."), clEnumValEnd),);After that, the rest of arguments are also particular of the option selected as the first argument, i.e, the rest of arguments are related with the first one. So I thought I could independently parse these arguments with:cl::list<std::string> Argv (cl::ConsumeAfter, cl::desc("<program arguments>..."));But, doing this when I run:myTool option1 file.cpp --I got the next error:"error - this positional option will never be matched, because it does not Require a value and a cl::ConsumeAfter option is active!"So, I modify "OptionsLeve</p>
</blockquote><p>lOptionsLevel" including the cl::Required flagThe error is now:"option: does not allow a value! option1 specified.option: must be specified at least once!option: must be specified at least once!option: must be specified at least once!"Then, I decided to use cl::PositionalEatsArgs instead of cl::ConsumeAfter. Then, this is the result:"option: does not allow a value! option1 specified."But, this time, the program continues. However, if I run "myTool option3 arg1 file.cpp --" it gives me a different problem:"warning: ../build/arg1: 'linker' input unusederror: unable to handle compilation, expected exactly one compiler job in ' '"But the program still goes on.Is there a way to accomplish what I have explained? I don't want those errors and warnings. Thanks,Pedro.</p>
<blockquote class="replyBlock" style="border-left: 2px solid #000083; margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><p>_______________________________________________<br/>
LLVM Developers mailing list<br/>
LLVMdev@cs.uiuc.edu <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br/>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></p>
</blockquote></blockquote>
</body>
</html>