search

mono / CppSharp

Tools and libraries to glue C/C++ APIs to high-level languages
MIT License
3.13k stars 516 forks source link

incorrect LLVM and Clang revisions #301

Closed karliss closed 10 years ago

karliss commented 10 years ago

Last revision known to work in Getting Started is incorrect. It should be at least r213557 ( llvm-mirror/llvm@95689f0845b0b6344d78746522a14790358e49f4 ) due to changes in 76e254e766c3eb99f888d57fa6e26fa2ad41657f Having to dig through commit history for both CppSharp and Clang to guess the correct Clang/LLVM revision is very unfriendly for people new to this project. Some ideas for improving this:

What is the status of patches form patch folder? One of them is 8 month old. Are they still required, anyone working on having them reviewed and merged ?

tomba commented 10 years ago

Maybe git submodules could be used for llvm and clang. That'd make the llvm & clang versions clear, and they would also keep in sync with the cppsharp (i.e. if you checkout an old version, you'd also easily get the llvm & clang that worked with that version).

karliss commented 10 years ago

Sounds good.

tritao commented 10 years ago

I'm sorry about this, I agree it's a huge pain in the ass to have to track down build failures, especially if you're just getting started..

This wouldn't be such a problem if the build bot infrastructure was running (it decided to stop working a couple weeks ago and I haven't fixed it since)... Usually every time I updated the LLVM revisions in the bot I'd also update the LLVM revisions in the docs.

Using submodules has been suggested plenty of times before and I think we should move to them for all the reasons already mentioned. I just have been caught up in other work and haven't done yet. Feel free to send a pull request or wait until I get to it.

About the patches, the old one should just be deleted. About the COFF one, I think @ddobrev is working on getting it merged upstream. It's not a huge priority because unpatched LLVM will still work fine.