[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