search

microsoft / WinObjC

Objective-C for Windows
MIT License
6.24k stars 808 forks source link

Move to a custom build of Clang 6.0.1 #2869

Closed DHowett-MSFT closed 6 years ago

DHowett-MSFT commented 6 years ago

This pull request moves WinObjC to Clang 6.

Fixes #2837, #2806, #1647, #405, #2341, #1140, #160. Closes #1769.

This change is Reviewable

DHowett-MSFT commented 6 years ago

This pull request also breaks ARM support.

DHowett-MSFT commented 6 years ago

Fixes #2837 #2806 #1647 #405 #2341 #1140 #160. Closes #1769.

DHowett commented 6 years ago

TODO: Include patches in tools/msvc/patches, but don't package them.

MSFTFox commented 6 years ago

Why the custom build of clang 6? I thought the intention was to move away from having our own binaries here. Edit I realized this is probably an intermediate step as our proposed changes get merged with official binaries. There's no reason for us to halt changes blocked on outside dependencies.

DHowett-MSFT commented 6 years ago

We have clang changes that may never be suitable for upstreaming; our compromise is to upstream what we can and provide patches for what we can't.

wjk commented 6 years ago

I have a question about this PR. I noticed that the MSVC-derived binaries in the LLVM/bin folder (mspdb*, c2.dll, etc.) have been removed. Having watched Clang's upstream development, I know that their MSVC compatibility (and, in particular, their ability to generate and manipulate PDB files) is much improved over where it was just a few years ago. Furthermore, @DHowett-MSFT's comment about "clang-6.0.0+ms" implies that we are moving to upstream(-ish) Clang instead of a heavily modified, Microsoft-specific fork. Should this PR be merged, will it mean that the Clang compiler used will be open-source (or, at least, can be replaced with a self-built Clang and not cause too much breakage)?

Even though WinObjC was never really suitable for its intended purpose IMHO, I still think it has some interesting ideas under the hood that I might want to extract and use in my own projects. (In particular, I was thinking of adding support for the Mac frameworks — AppKit et al — as well as the iOS ones, and creating a macOS-to-Windows app bridge.) Should the Microsoft-proprietary compiler be finally removed, this would greatly aid the implementation of these ideas.

Thanks for answering my question, and keep up the good work! 😄

DHowett-MSFT commented 6 years ago

Hi @wjk!

That's a very astute observation. We're planning on upstreaming any Clang changes that make sense and switching to an upstream build at our earliest convenience. For now, though, we have patches staged for upstreaming in issue #2860, and the ones that haven't made it up will be included in this pull request.

I'm very interested in your plan to support Mac frameworks. Would you mind e-mailing me at duhowett@microsoft.com to continue this conversation?