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

[Ruben Van Boxem]

2011/4/22 Douglas Gregor <dgregor at apple.com>

>
> On Apr 22, 2011, at 12:25 PM, Reid Kleckner wrote:
>
> > I didn't interpret his suggestion that way, I thought it was more
> > along the lines of doing what the 'which gcc' command does.
>
> 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.
>
>
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).

Does Clang have any functions to read files/directories or is that a task
for the Win32 API?

Ruben



>        - Doug
>
> > 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
> >>
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110422/93c21256/attachment.html>