[LLVMdev] CommandLine: using cl::Positional with enum

[Daniel Liew]

Hi,

Please try and format your e-mails better. Your e-mail is incredibly
hard to read due to its lack of new lines.

I don't think the designer of the CommandLine library ever intended for
cl::Positional to be used with cl::opt<T> where T is an enum.

e.g.

enum OptLevel {
  g, O1, O2, O3
};

cl::opt<OptLevel> OptimizationLevel(cl::desc("Choose optimization level:"),
  cl::values(
    clEnumVal(g , "No optimizations, enable debugging"),
    clEnumVal(O1, "Enable trivial optimizations"),
    clEnumVal(O2, "Enable default optimizations"),
    clEnumVal(O3, "Enable expensive optimizations"),
   clEnumValEnd),
   cl::Positional
   );

int
main (int argc, char ** argv)
{
  cl::ParseCommandLineOptions(argc, argv);

  // Easy access in gdb (getValue is inlined!)
  OptLevel* test = &(OptimizationLevel.getValue() );
}

It also doesn't make a huge amount of sense (based on the output of
-help) either because the OptimizationLevel options have the "-" prefix
which is almost always taken to mean that it is optional and NOT
positional. -help shows...

  Choose optimization level:
    -g               - No optimizations, enable debugging
    -O1              - Enable trivial optimizations
    -O2              - Enable default optimizations
    -O3              - Enable expensive optimizations

Trying

$ ./program -O1
$ ./program O1
$ ./program -- -O1
$ ./program -- O1

does not result in OptimizationLevel being modified by calling
ParseCommandLineOptions (I tested this in gdb).

This behaviour is arguably a bug. You're welcome to try and fix it.

I would like to suggest an alternative though. If I understand you
correctly you're looking for your command line syntax to be something
like...

./prog <option1> | ( <option2> --arg1 --arg2) | ( <option3> --arg1 )

I don't see why you should really care about the order, i.e. this is
probably okay.

./prog --arg1 <option1>

So why not make every argument optional (i.e. no positional arguments)

then after calling ParseCommandLineOptions you can check the user has
used the right options by doing something like...

// Note cl::opt<T> is a type of Option
Option* NOTValidForOption1[] = { &arg1, &arg2};
Option* NOTValidForOption3[] = { &arg2 };

switch(YourOption)
{
   case Option1:
     for(int I=0; I < sizeof(NOTValidForOption1)/sizeof(Option*);++I)
     {
        if(NotValidForOption1[I]->getNumOccurrences() != 0)
        {
           //Fail
        }
     }
     break;

    case Option2:
      break;

    case Option3:
      // similar to Option1
}

^ Note the above certainly code be coded better, this is just to give
you an idea.

You could also make it more obvious in the output of -help that only
certain options should be used with each other by putting them into
categories (see cl::cat() in documentation). Note this will only work
for you if arguments are mutually exclusive as an option may only be in
one category.

Hope that helps.

Dan.

On 07/05/13 08:58, Pedro Delgado Perez wrote:
>  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:
> 
> 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 "O!
 ptionsLeve
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.
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>