<div>Hello Chris,</div><div><br></div><div>We're using LLVM CommandLine 2.0 Library in the <font face="courier new, monospace">clang-check</font> tool. Overall it works fine for us, but there are a couple of problems related to the library design and current usage patterns.</div>



<div><br></div><div>First, there's a <a href="http://llvm.org/docs/CommandLine.html#exploiting-external-storage" target="_blank">feature</a>:</div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><i>"Several of the LLVM libraries define static cl::opt instances that will automatically be included in any program that links with that library. This is a feature."</i></div>



</blockquote>which is useful in some scenarios, but sometimes it causes headache. For example, <font face="courier new, monospace">clang-check</font> now has a number of unrelated options in -help output:<br clear="all">


<div><div><font face="courier new, monospace">  -fatal-assembler-warnings        - Consider warnings as error</font></div>
<div><span style="font-family:'courier new',monospace">  -mc-x86-disable-arith-relaxation - Disable relaxation of arithmetic instruction for X86</span></div><div><span style="font-family:'courier new',monospace">  -stats                           - Enable statistics output from program</span></div>



<div><span style="font-family:'courier new',monospace">  -x86-asm-syntax                  - Choose style of code to emit from X86 backend:</span></div><div><font face="courier new, monospace">    =att                           -   Emit AT&T-style assembly</font></div>



<div><font face="courier new, monospace">    =intel                         -   Emit Intel-style assembly</font></div></div><div><br></div><div>We definitely need to link to the relevant libraries, but we don't make use of these options. Could we have a more flexible way to define options available in a certain binary? Maybe some sort of defining option sets or categories? Or a way to create a local command line parser and bind cl::opt objects to it? Or any other suitable solution?</div>


<div><br></div><div>The second problem is that we would like to have a base class for clang tools, which has it's own help message and a set of common options. It would also be useful to be able to specify option descriptions dynamically. Currently it's implemented using a local cl::opt/cl::extrahelp objects so that the order of creation can be defined more explicitly (r161753). But I'm not sure this is a supported use-case. I've added a test for it (r161751), but it would be nice to make sure if it aligns well with the library design plans.</div>



<div><br></div>-- <br><div>Best regards,</div><div>Alexander Kornienko</div><br>