[cfe-dev] Clang universal driver project state

Simon Atanasyan simon at atanasyan.com
Mon Aug 5 08:27:26 PDT 2013


On Fri, Aug 2, 2013 at 9:48 PM, David Blaikie <dblaikie at gmail.com> 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))
>
>>With those in place, response file should
>> work. Including the idea of writing a tool that run gcc and extracts a
>> configuration file.

First of all thanks for all your response. Let me sum up.

1. In general response files solve the problem. Though they have some
shortcomings:
  a) MIPS toolchain requires ~35 separate response files to cover all
possible combinations of options. Some paths in these files are the
same but user has to duplicate them in each file.
  b) Response files are independent of command line options. User has
to use them consistently.

2. As far as I understand there is no objection to implement a tool
that run gcc and create a response file acceptable the clang.

Let's postpone (at least temporarily) the discussion on the driver's
configuration file format. I'll write a tool for response file
generation. Maybe that close the issue. Any suggestion and ideas are
welcome.

Regards,
Simon




More information about the cfe-dev mailing list