Support for raw build commands?

[luxe]

Use Case

We would like to create a static analysis tool which takes the command line as input and uses this library to parse the AST for analysis. Cppast supports clang's compilation database which seems like the most compatible way of ensuring correct parsing. However, some build systems do not generate these database files, and it's instead easier to feed the raw CLI during the build phase. Other tools such as clang-tidy, and IWUY support this strategy of taking the build flags via CLI.

Processing Raw Commands

This library already has a generic add_flag method which should make it possible to provide the correct flags based on a build command. However, there is also an API that chooses appropriate flags based the context given; such as language standard, include dirs, macros, etc.

Worth Extending?

I'm wondering what your thoughts are on extending cppast to have an API that takes a build command, parses it, and adds the appropriate flags needed to the config. In this case, it would be a superset implementation of calling all of those above API methods individually. Without this being in the library, I see two possible ways of creating libclang_compile_config:

1. Push the responsibility to the build system / tool. Use something like Bear to get the compilation database.
2. Custom C++ code that parses the CLI, extracts the necessary flags, and builds a libclang_compile_config with add_flag.

Alternatively we provide a method to libclang_compile_config that takes a build CLI alongside the existing compilation database methods.

Just curious your thoughts; thanks!

[foonathan]

I'd like to keep the base class compile_config very abstract and not be concerned with particular flags at all. As such:

Alternatively we provide a method to libclang_compile_config that takes a build CLI alongside the existing compilation database methods.

That one can work. It accepts the clang specific options, and passes them along unchanged. My only concern is that users might be able to pass flags that would break libclang/override the flags we're hardcoding. Some form of sanitziation might be necessary, or we just warn the user in the documentation that they should not do that.

I welcome a PR that explores this area further. :)