Hunterize v3.0.0 #3
Conversation
Fix #include in js_generator.cc
Export class Arena to shared library.
Bump objc podspec version number
- Add the folder CocoaPods will add to the root folder. - Move and expand the entries in the objectivec directory.
Ruby oneofs: return default instead of nil for unset fields.
- Add an Xcode 6.3 created default iOS Project. - Add an Xcode 6.3 created default OS X Project. - Add Podfiles to for both that use Protobufs from within the tree. - Add a script to run the tests (and cleanup) to help confirm the state of the Protobuf.podspec and sources.
OS X gitignore cleanup and cocoapods integration tests
Otherwise the projects have to be opened once to create user schemes for the command line builds to work.
Add shared schemes for the CocoaPods integration tests
…mpliant (See the description of cmake's config search behavior on https://cmake.org/cmake/help/v3.4/command/find_package.html)
… variables (PACKAGE_VERSION_EXACT, PACKAGE_VERSION_COMPATIBLE, PACKAGE_VERSION_UNSUITABLE)
- Env solution doesn't seem to always work, use template pod files and copy them in place instead. - Flush the pods cache before and after runs. - Make pod install verbose to have the info incase something goes wrong.
Make cmake configuration file install path configurable
Make protobuf-config-version.cmake.in set the required variables
…n_followup Make the CocoaPods integration tests more robust
Add compatibilty tests against v2.5.0
…mespace Add protobuf:: namespace to installed targets
added missing closing bracket for _cmakedir_desc in cmake/install.cmake:88
- Add generator constant for the default framework name. - Add generator api for making the CPP symbol from the name. - Add generator api to see if it is a bundled proto file. - Output a CPP conditional and two imports for the core library headers. - Add helper for generating the #import for file headers to deal with the framework imports. - Add a reference from the unittests to a WKT to use that to inspect how imports generate. - Update the podspec to define the CPP symbol and require pods 1.0 (or later). Fixes protocolbuffers#1457
Add js/binary/encoder.js to js_EXTRA_DIST.
Better support for using the proto library from a framework.
- Move the ObjC tests into the list and exclude them on linux, this will change where in the order they start, since they are longer, it will have other things run in parallel instead of them ending up last and taking the longest. - Switch to the Xcode 7.3 image. - Drop the use of xctool and stream line things through the full_mac_build.sh script. This means we end up with only one build script instead of two. - Tweaks to the mac build script: - Make iOS Xcode version support explicit - Support Debug/Release only building - Change the OS X min parallel count to 2 to better deal with VMs. - Split the travis ios tests into the two Xcode Configurations as the logs are choking travis.
Automated testing tweaks for ObjC
Working on protocolbuffers#1599, specifically: - Turn on more warnings that the Xcode UI calls out with individual controls. - Manually add: -Wundef -Wswitch-enum - Manually add and then diable in the unittests because of XCTest's headers: -Wreserved-id-macro -Wdocumentation-unknown-command - Manually add -Wdirect-ivar-access, but disable it for the unittests and in the library code (via #pragmas to suppress it). This is done so proto users can enable the warning.
Remove the use of INT64_C/UINT64_C and add static_cast when neccessary.
Fixes traivs cpp build.
Make protoc-artifacts able to build plugins.
Change log for 3.0 GA release.
Have you tried
Fork branches should match upstream, so |
|
I agree. But the hunter branch in this repo does not contain the hunter-related changes at all. I suspect the branch
|
This is how things should look like :) @tatraian can you consult us with the current state?
It should fit upstream. Is v3.0.0 a separate branch or just a tag from branch master? |
|
The upstream tag In this fork there is a branch named |
|
@Osse okay, can you please do |
|
Thanks for having faith in me :) I have made it so that the master branches are equal. And also pushed my hunterization of 3.0.0 and tested it. But before I push , I have a question: @tatraian added the |
|
It says it's closed but it isn't. I force-pushed it away (sorry). I am also waiting for an answer to this question before making things final: protocolbuffers#1931 |
Follow upstream. This is one more reason to push non-Hunterized patches upstream instead of keeping them in fork. Just don't forget to edit wiki page.
What is closed, this pull request? I think since you pushed that code to branch manually GitHub is smart enough to figure out that changes from this pull request already merged. |
|
Ok, I will stick to upstream as close as possible. This is what the hunterization looks like so far: hunter...Osse:hunter Summary: I use the most recent Hunter and Huntergate , cherry-pick a bunch of fixes to the CMake files since 3.0.0, and change I must admit my original pull request did a lot of stuff wrong. Also I think the CMake setup they have upstream is a bit strange, but I'm a novice. |
|
Sorry Guys, I was out. I planed to update this repo as follows: |
|
@tatraian sounds pretty similar to what we are trying to do as far as I understand. Probably except cherry-picking, since tags created in upstream branch |
|
@tatraian Hi, welcome back :) Yes, what you describe is exactly what my original plan was. However there were conflicts. Many of these conflicts were due to upstream making changes similar to what the hunterization consisted of in the first place. Which is a good thing, I suppose. So I ended up looking at the diff between |
|
@Osse As I remember not only @ruslo At the first release it is easier to make a merge to a "generic" hunter branch. But after the original project update, you have to merge into the same branch. In case of CMake files this will be hard after some releases (but you have experience in this). |
Why? If merge has conflicts then cherry-pick will have them too, but if there is no conflicts instead of doing several cherry-picks you can |
|
You are right. That's seems easier, I prefer cherry pick because I see harder in "merge style" history what happened exactly. |
This ended up being a huge PR so I don't think this is the best way of doing it. But in any case in my fork you will find a tag named
v3.0.0-hunter-1. I created this by looking at the changes betweenv3.0.0-beta-2andv3.0.0-beta-2-hunter-2and making the equivalent changes on top of thev3.0.0tag.