<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 14, 2012, at 2:35 PM, Alexander Kornienko <<a href="mailto:alexfh@google.com">alexfh@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><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></blockquote><div><br></div><div><br></div>Since the library was rewritten (as "2.0!") in 2002, LLVM has evolved quite a bit. The command line parsing library, sadly, hasn't. :-(</div><div><br><blockquote type="cite"><blockquote style="margin:0 0 0 40px;border:none;padding:0px">
</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></blockquote><div><br></div><div>Yes, this is a major problem. Realistically, just hiding these options isn't a great solution either though: if you are building a tool that you want a sensible command line argument syntax, then you simply can't use the cl library. This is sad, but reality. This is one reason why clang (for example) doesn't use the command line library.</div><div><br></div><div>It is possible to retrofit categories into the cl library, but it is really due for a rewrite anyway. Some general deficiencies:</div><div><br></div><div>- It needs categories, or some way to turn off all the debugging and tweaking flags, or hide them under a meta option like -mllvm.</div><div>- It needs to have StringRef pushed through it - it doesn't make sense to copy string data from the command line arguments into the std::string in a cl::opt<std::string> option, nor does it make sense for cl::init("foo") to do a malloc at startup time. </div><div>- It needs to be rewritten to avoid static constructors.</div><div>... probably lots more.</div><div><br></div><blockquote type="cite">
<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>
</blockquote><br></div><div>Clang uses a completely different command line option parsing library, so if you want an extension of what it provides, using cl is the wrong place to start.</div><div><br></div><div>-Chris</div><br></body></html>