[cfe-commits] Patch: reading clang configuration from yaml

[Sean Silva]

For a while I've actually thought it would be useful to have something
like this for the wider world of options. The part that I find most
interesting is establishing some canonical human-readable
representation for all of the compiler options. I think this has the
main benefit of being able to operate symbolically on the set of
options used for a particular invocation of the compiler.

One use case where I think this would be compelling is for tools. If
you look at the current state of the CompilationDatabase, it basically
saves verbatim the entire command line invocation for compiling each
file. However, most of the invocations are the same modulo the file
being compiled. It would be really nice to be able to factor out this
commonality in a human-readable way and be able to reason about it
symbolically.

Those are just my 2 cents. I'm not sure about the general usefulness
of your current patch though. Is there a particular use case that you
are addressing?

--Sean Silva

On Wed, Aug 15, 2012 at 9:59 AM, Josh Rickmar <jrick at devio.us> wrote:
> Hi,
>
> Let me start off by saying that this is my first time in the clang
> codebase, and also that my c++ is pretty terrible.  Anyways, I was
> asked to see if it would be possible to read some sort of clang
> configuration (using the llvm yaml parser) to set things like the
> linker and assembler binaries, and other include and library paths.
> This is a very rough patch (currently it only sets the modifies the
> linker and assembler binaries if changed in the conf), but at this
> point I'm just wondering if there's any enthusiasm to get something
> like this in, and other general suggestions on how to get this coded
> together.
>
> Anyways, with this patch it should be possible to create some yaml,
> for example:
>
> ---
> ld: /usr/bin/ld
> as: /usr/bin/as
>
> and then either save that in /etc/clang.yaml or point the CLANG_CONF
> environmental variable to it.  If after parsing the yaml, either of
> those settings were specified, the ToolChain::GetProgramPath()
> function will now return what was parsed from the yaml insteading of
> getting the full path from the driver.
>
> Again, this is very rough and needs a lot of work still, but any
> feedback is welcome.
>
> --
> Josh Rickmar
> http://jrick.devio.us/
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>