<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><div></div><div class="h5"><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 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).<br>

><br>
> 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.<br>
><br>
> Two things are required for this to work:<br>
> 1. Clang needs to be able to locate the gcc executable (from PATH), 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>
</div></div>Perhaps. This is a longstanding issue across platforms; probing GCC at ./configure time to find the paths it uses would probably be most effective.<br>
<br>
        - Doug<br>
</blockquote></div><br>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).<br>
<br>Ruben<br>