[cfe-dev] Clang universal driver project state

[reed kotler]

On 08/02/2013 10:48 AM, David Blaikie wrote:
> On Fri, Aug 2, 2013 at 8:40 AM, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
>>> This is a very simple and clean solution he is proposing.
>>> Clang should be able to read from a simple ascii file where the components
>>> of the target infrastructure are located: i.e. header files, assembler,
>>> linker, libraries, etc.
>> Why can't the files be response files? The driver already communicates
>> all the header info to cc1 via command lines. Having command lines for
>>   disabling autodetect and selecting the linker, library layout, etc is
>> good for testing anyway.
> Yep, this is what I was wondering/asking at the social last night. If
> all these options are (or should be) command line arguments for clang
> anyway, all we really want is the ability to specify a file containing
> command line arguments (this seems slightly different from a "response
> file" - I mean literally just a file containing command line args and
> a command line "-args foo.txt" & it just substitutes the contents of
> the file as if it were arguments immediately written there (so they
> override and can be overridden as usual))
Simon will have to explain all the details here.

He implemented this all in Clang for the Codesorcery (Mentor) toolchain 
and at least for Mips, that is probably about as complicated a toolchain 
as you are going to get. The multidimensional matrix
of processor types, headers, libraries, tools, etc. is pretty large.

Right now, we have a command option -gcc-toolchain=<name> where you give 
the root of the
Codesorcery distribution and then all the standard gcc mips options when 
passed to clang for Mips will interact with that toolchain properly.

Also, it's not necessary to convert all of what is already in Clang over 
to this new scheme, although I think that if done properly, people would 
want to transition to this and we could clean up a lot of code
in the driver.

People are free to do as they always have done there.

It's needed though for the embedded toolchain folks.

This was prototyped by us several years back in an alternate driver that 
we wrote in python.


Reed

>> With those in place, response file should
>> work. Including the idea of writing a tool that run gcc and extracts a
>> configuration file.