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.”
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.