On Tue, Apr 8, 2014 at 6:32 PM, Reid Kleckner <[email protected]> wrote: > On Tue, Apr 8, 2014 at 9:09 AM, Andrea Di Biagio <[email protected]> > 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 <[email protected]> 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
