On Aug 14, 2012, at 2:35 PM, Alexander Kornienko <alexfh at google.com>
wrote:
> Hello Chris,
>
> We're using LLVM CommandLine 2.0 Library in the clang-check tool.
Overall it works fine for us, but there are a couple of problems related to the
library design and current usage patterns.
>
> First, there's a feature:
> "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."
Since the library was rewritten (as "2.0!") in 2002, LLVM has evolved
quite a bit. The command line parsing library, sadly, hasn't. :-(
> which is useful in some scenarios, but sometimes it causes headache. For
example, clang-check now has a number of unrelated options in -help output:
> -fatal-assembler-warnings - Consider warnings as error
> -mc-x86-disable-arith-relaxation - Disable relaxation of arithmetic
instruction for X86
> -stats - Enable statistics output from program
> -x86-asm-syntax - Choose style of code to emit from X86
backend:
> =att - Emit AT&T-style assembly
> =intel - Emit Intel-style assembly
>
> 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?
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.
It is possible to retrofit categories into the cl library, but it is really due
for a rewrite anyway. Some general deficiencies:
- It needs categories, or some way to turn off all the debugging and tweaking
flags, or hide them under a meta option like -mllvm.
- 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.
- It needs to be rewritten to avoid static constructors.
... probably lots more.
> 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.
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.
-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120814/70d1b6aa/attachment.html>