LLVM CommandLine 2.0 Library Usage

Project Infrastructure LLVM Dev List Archives
1

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

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.

2

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. :frowning:

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::optstd::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