[cfe-dev] Clang on Windows targeting gcc requirements

[Edward Diener]

On 6/25/2015 11:34 PM, Nikola Smiljanic wrote:
>
>     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
>     c:\mingw.
>
>     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
> checkout/clone.

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.