[cfe-dev] [LLVMdev] Windows strategy?

Mikael Lyngvig mikael at lyngvig.org
Mon Jun 11 12:39:39 PDT 2012

Thanks for your extensive answer!  I now better understand the processes
involving LLVM and Clang.  I figured you were like most FOSS projects: A
group of dudes working more or less together towards a common objective and
therefore wanted to try to tune that objective.

I have contributed a Mingw64 Windows buildbot slave that fails predictably
in 29 tests on each build, and I will happily offer more CPU power down the
road.  In fact, I was looking at AMD FX 8150 (eight core) processors for
yet another Windows buildbot slave earlier today, but it gets poor reviews.
 I'll figure something out later.

I no longer see support of the Microsoft C++ ABI as a decisive feature -
people can simply recompile their sources and that's it.  In fact, I think
it is much more important to do a full binary release of Clang32/Clang64
using MinGW.  Besides, there's the patent issues with supporting the
Microsoft C++ ABI (I posted links to some reverse engineering articles on
Microsoft C++ and they listed a whole slew of Microsoft patents in the
area).  Also, the whole idea of using Clang and Microsoft Visual Studio
together is sort of like using a vacuum cleaner and a broom together.

I understand things much better now, thank you for that.  And I'll study
the 3.2 docs first thing tomorrow.

2012/6/11 Chandler Carruth <chandlerc at google.com>

> On Mon, Jun 11, 2012 at 10:52 AM, Mikael Lyngvig <mikael at lyngvig.org>wrote:
>> Hi,
>> [Synopsis: Mikael thinks Windows support is overlooked and that this is a
>> strategic error. ...]
> Synopsis of my response: It is not overlooked, it has some technical,
> non-technical, and manpower limitations.
> Allow me to briefly summarize these issues:
> Technical: Currently, we have a shortage of build infrastructure and test
> infrastructure of high quality running windows. This limits the amount of
> testing that target gets, and limits the ability of non-windows-hosted
> developers to recognize when their patch causes a problem.
> Non-technical: Currently, there is an unofficial policy that is in place
> limiting what parts of Windows support we're pursuing. Feel free to reach
> out to me directly for details, but here is a summary of the strategy that
> I discussed with Doug Gregor and several others:
> - MingGW and Cygwin in all of their various forms are fine. Patches
> extremely welcome here, these should be first-class supported platforms.
> - Documentation is always welcome, and much needed. Please contribute more
> here. =]
> - Win64 ABI, mangling, etc. compatibility is fine. Patches are quite
> welcome here, and please cite the win64 spec[1] for what your patch fixes.
> - We are not planning to do more work on Win32 ABI. Some bug fixing (name
> mangling, etc) is fine, but I would encourage development efforts to focus
> on Win64, and get that working instead. We may decide to support some
> subset of Win32, but that's in the future.
> - Supporting well specified Windows language extensions is welcome. See
> the declspec work for great examples of this.
> - We are working to figure out the best way to support parsing the Windows
> headers, but this is a complex issue. Expect some patches to clear the way
> in the not-too-distant future.
> [1] (http://msdn.microsoft.com/en-us/library/7kcdt6fy(v=vs.110)
> My view is that the aspiring Clang++ Windows user is in for a nightmare
>> reverse walk through a night time minefield with both eyes shut.
> Yes. See documentation point above.
> So, I am wondering if there is anything that can be done to help this
>> situation?   I'd love great ideas from you guys, even though I am getting
>> rather used to getting no responses to my mails ;-)  I am willing to invest
>> considerable amount of time into helping with this, I just cannot do
>> serious C++ coding at this point because I am yet too rusty in C++ and
>> because I am busy, busy, busy with my own project (a compiler that uses
>> LLVM as its backend).
> Patches are likely to be necessary here, but patches to things like
> documentation can be done even w/o much C++ expertise.
> 1. Priority is put into making MinGW64 work
> Please understand, each developer has their own priorities. Yours are
> Windows support, and that is excellent, but other developers cannot simply
> shift their priorities around. We need new contributors (like yourself) to
> prioritize Windows because of their interest and investment in the platform.
>> 2. If nobody (including licenses) object to it, I'd like to make two
>> unofficial Windows distributions of Clang: clang-3.2-win32 and
>> clang-3.2-win64.
> These would, I suspect, not be "official" releases. Please join in the
> release testing and qualification process for the next Clang release
> though! We need people to help test and qualify the release (and build
> binariy packages) for platforms like Windows.
> There is documentation on the website about how to join this effort for
> the 3.2 release cycle.
>> 3. I will eagerly hunt down every opportunity to document Windows
>> specifics a bit more.  I have received no feedback, whatsoever, on my
>> Windows build document so I take it that it is not to the dev group's
>> liking.  So be it.  Life goes on.
> Wait, what document? I missed it. =[ Can you ping the thread? We are all
> dealing with a very large email load, but I assure you there *is* interest
> here. You may have to help us keep track of the email thread and get you
> feedback, but it's not a lack of interest.
>> 4. Please give me your ideas for how I can contribute to the Windows
>> support without actually hacking on LLVM and Clang (yet)!
> I hope I've done so...
> One point I have to make however is that this:
>> 1. 97.7 percent of the world's computer users are Windows users.
> is not an effective argument. ;] All of the developers on Clang/LLVM are
> working because they have some specific itch to scratch. Some of the
> developers are employed by companies that have a corporate itch to scratch
> with Clang. These often represent significant user bases, and are investing
> time to directly support them. It's not about Windows vs. Linux vs. other.
> It's about users that *I* am directly responsible for supporting, and their
> needs trump.
> Just be aware of that. ;] Also, there are a lot of Mac users out there.
> Just saying.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120611/47236ca8/attachment.html>

More information about the cfe-dev mailing list