[cfe-dev] MinGW header search paths (InitHeaderSearch.cpp)

[Reid Kleckner]

I didn't interpret his suggestion that way, I thought it was more
along the lines of doing what the 'which gcc' command does.

Reid

On Fri, Apr 22, 2011 at 2:59 PM, Douglas Gregor <dgregor at apple.com> wrote:
>
> On Apr 22, 2011, at 8:49 AM, Ruben Van Boxem wrote:
>
> 2011/4/22 Douglas Gregor <dgregor at apple.com>
>>
>> On Apr 21, 2011, at 8:07 AM, Ruben Van Boxem wrote:
>>
>> > I noticed a big blob of ugly code in InitHeaderSearch.cpp, especially
>> > when MinGW is involved. Aside from its atrocity, it assumes that MinGW is
>> > installed in c:\..., which is not true for my system (and may not be true
>> > for others as well).
>> >
>> > I would propose to change this hackery to a single (set of) path(s)
>> > deduced from the location of the gcc executable used to link the Clang
>> > generated object files together.
>> >
>> > Two things are required for this to work:
>> > 1. Clang needs to be able to locate the gcc executable (from PATH),
>> > including version and target info (for step 2)
>> > 2. Relative paths need to be generated from that location.
>> >
>> > Is this a sensible way of solving the problem?
>>
>> Perhaps. This is a longstanding issue across platforms; probing GCC at
>> ./configure time to find the paths it uses would probably be most effective.
>>
>>        - Doug
>
> I was thinking of a runtime search, to allow Clang to be moved/installed in
> Windows. Not the most efficient, but workable untill it's not necessary
> anymore (ie Clang grows independent of GCC).
>
> Having Clang call GCC every time it is invoked seems like an unacceptable
> performance penalty to me.
> - Doug
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>