Does it normally take 9 months or more to review a fix ?
Normally no, but not many people are interested in mingw which is why we
don't have proper driver support in the first place.
It does not sound like clang on Windows targeting gcc is very important to clang. That's a shame because clang on Windows targeting VC++ has no priority on Boost and only clang on Windows targeting gcc gets Boost testing. The main reason for that, as I have pointed out in the past, is that Boost PP library can't be bothered trying to emulate clang's version of VC++'s broken preprocessor, whereas clang on Windows targeting gcc provides a C++ standard conforming preprocessor.
People who review
are pretty busy so it's patch authors responsibility to remind them,
it's unfortunate but we've had many patches lost this way. I send pings
every week or so for my patches that go unreviewed.
The hardcoded paths clang currently uses all appear to be off of
It does not appear to be the case that version numbers are
hardcoded. I can test the clang binaries for clang-3.4.1,
clang-3.5.2, clang-3.6.1, and the latest clang-3.7 built from source
all against the latest mingw distribution, which uses gcc-4.8.1, and
is linked to from c:\mingw without any problems. If each clang
release hardcoded the mingw version, by which I am guessing you mean
of course the gcc version, it is doubtful that all the different
clang releases I mentioned would work with the gcc-4.8.1 release.
Have a look at InitHeaderSearch.cpp, it has a list of mingw versions,
and as you point out paths start with c:/mingw
I will look at it.
If this fix removes the hardcoded c:\mingw path when searching for a
gcc distro to use, how does the end-user tell clang where the gcc
distro he wants to use with clang resides ?
I can't answer this one.
Perhaps the patch is only for support of mingw-64 as the gcc target but the reliance on c:\mingw remains. Support for mingw-64 is nevertheless a large step in the right direction since mingw-64 is the the mingw distro of choice for many Windows programmers using gcc. Linking c:\mingw to a mingw-64 distro is easy but it would really be better if there were some way to point to the mingw-64 distro you want to have clang use when invoking clang rather than relying on a hardcoded path.
I gather then that the patch file is a subversion patch file. From
where in the llvm tree do I apply the patch ? How do I know that the
patch will work with the latest llvm/clang source I have updated
from the llvm/clang sunversion repositories ? Or is the patch only
valid for a particular version of clang and not the latest version
from source ?
It's either svn or git patch, you're supposed to apply it to clang
Does llvm/clang have a git interface ? I assumed that subversion is still being used. I have found that git is a more flexible SCCS than subversion but the latter is still quite usable.
That would be llvm/tools/clang for a usual in-tree
setup. As with any other patch, it was generated from specific source
version, but since this code doesn't change too much you should be able
to apply it cleanly to trunk with a little bit of luck.
I will checkout a separate version of the latest llvm/clang to try it out. I don't like messing up my normal clang source build on Windows by applying patches and then worrying that each new update to llvm/clang is going to conflict with a patch.
If you'd like to get this checked in, email patch authors, give hand
testing/reviewing the patch and try to get things rolling, it's been a
while since last comment in the review.
I will do my best but I am really surprised that the clang/Windows/gcc version of clang doesn't get much attention among clang development.