[cfe-dev] Clang universal driver project state

[Reed Kotler]

On 08/05/2013 08:27 AM, Simon Atanasyan wrote:
> 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.
>
I don't know anything about response files but from what you are saying, 
it sounds like it also might be possible to write a standalone tool for 
generating response files.  Maybe some simple python script for this 
response file generation would be easiest.

I agree that for now to be able to derive this from a gcc toolchain is 
the most useful since it's not likely that someone, at this exact time , 
will be doing LLVM work on any target that does not also have a normal 
gcc like tool chain with binutils, libc, etc. In that case, the command 
line options in gcc for telling you about the specifics of the toolchain 
as input to the tool you propose, would be the most helpful.


> Regards,
> Simon
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>