[cfe-dev] Clang on Windows targeting gcc requirements
eldlistmailingz at tropicsoft.com
Fri Jun 26 00:53:15 PDT 2015
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
> 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.
More information about the cfe-dev