On 08/15/12 12:17, Sean Silva wrote: > 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?
Well I would use it to make cross-compiling stuff much more easy. Currently in the Driver directory several OS' hard code a whole bunch of directories (like C++ includes etc). A change requires a recompile but with this life's good. Also being able to set this between runs really makes debugging clang driver changes a whole lot easier. I love the idea :) > > --Sean Silva > > On Wed, Aug 15, 2012 at 9:59 AM, Josh Rickmar <[email protected]> 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 >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
