[LLVMdev] LLVM CommandLine 2.0 Library Usage

Alexander Kornienko alexfh at google.com
Tue Aug 14 14:35:12 PDT 2012


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<http://llvm.org/docs/CommandLine.html#exploiting-external-storage>
:

*"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."*

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?

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.

-- 
Best regards,
Alexander Kornienko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120814/548c9ea1/attachment.html>


More information about the llvm-dev mailing list