[cfe-dev] Clang on Windows targeting gcc requirements
mfaithfull at btopenworld.com
Fri Jun 26 01:40:19 PDT 2015
Interesting note on Boost PP. I'm not sure why VC++ is still broken given that they have been using EDG front end since 2013?
I have a Boost PP port which seems happy under MinGW GCC, Clang and VC++ on Windows though I don't have anything like a full test suite to prove correctness.
The only issue I know of is Boost PP disables variadic macros on the assumption that being MSVC they're not available but actually __EDG__ is defined and they should be enabled. The definition ordering is tricky and I haven't worked out a fix yet.
All information at least 6 months old so apologies if I'm out of date. I've been out the game for months. Haven't touched any code. Don't even have fixed line internet till tomorrow.
----- Reply message -----
From: "Edward Diener" <eldlistmailingz at tropicsoft.com>
To: <cfe-dev at cs.uiuc.edu>
Subject: [cfe-dev] Clang on Windows targeting gcc requirements
Date: Fri, Jun 26, 2015 08:53
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.
cfe-dev mailing list
cfe-dev at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev