<div class="gmail_quote">2011/4/22 Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Apr 22, 2011, at 12:25 PM, Reid Kleckner wrote:<br>
<br>
> I didn't interpret his suggestion that way, I thought it was more<br>
> along the lines of doing what the 'which gcc' command does.<br>
<br>
</div>Ah, my mistake. We could try that for mingw at least. In general, it doesn't work as well as actually invoking GCC, since every build of GCC seems to like to put its standard library in a different place.<br>
<br></blockquote><div><br>That was indeed my plan. We can perhaps read the <gcclocation>/../include/c++/ subfolders with random/all versions/targets and add them to the search directories. Once libcxx works with mingw and on windows in general, we can get rid of this foolishness and just add the <clang(++)location>/../include(/c++) and be done with it (for Windows at least).<br>
<br>Does Clang have any functions to read files/directories or is that a task for the Win32 API?<br><br>Ruben<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

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