[PATCH][Driver] Teach the clang driver how to correctly parse response files on Windows.

Andrea Di Biagio andrea.dibiagio at gmail.com
Tue Apr 8 12:00:17 PDT 2014


On Tue, Apr 8, 2014 at 6:32 PM, Reid Kleckner <rnk at google.com> wrote:
> On Tue, Apr 8, 2014 at 9:09 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com>
> wrote:
>>
>> Hi Reid,
>>
>> thanks for the very useful feedback and sorry for the late reply...
>>
>> On Tue, Apr 1, 2014 at 4:18 AM, Reid Kleckner <rnk at google.com> wrote:
>> > Whoops, missed this over vacation.  My intention was to conditionalize
>> > this
>> > on the driver mode, i.e. clang-cl or gcc-style, but that computation
>> > happens
>> > further down, so I never got to this.
>> >
>> > The big question is, which syntax does mingw gcc understand?  If it's
>> > the
>> > libiberty style escaping, then the ifdef won't work, since clang could
>> > be
>> > either mingw gcc or MSVC's cl depending on argv[0].
>>
>> So, I just tried mingw (mingw32-gcc - gcc version 4.8.1) on a windows
>> host.
>> Unfortunately,  when expanding response files, mingw seems to
>> understand a different syntax than MSVC's cl.
>
>
> That's what I expected.  We can't really parse command line flags until
> we've expanded response files, so we don't know if we're targeting mingw or
> not.  Our best approximation is the driver mode: clang-cl vs. gcc/g++.  Is
> this enough for your usage, or do you need to use the gcc frontend with
> Windows-style response files?

Unfortunately in my case I would need the gcc frontend to use
windows-style response files.

> We could attempt to parse the command line before expanding response files
> to look for --target=.  Then we could use gnu tokenization only if the
> triple isOSCygMing().

Good idea, I'll have a look at it and see if it helps solving the
problem in my case.

Thanks!
Andrea



More information about the cfe-commits mailing list