I'm not exactly sure why, but this fixes the failing Bazel presubmit
test. Using the most recent version seems like a good idea anyway so
that we can make sure we're compatible with any new Bazel changes.
* Bump target frameworks from netcoreapp1.0 to netcoreapp2.2.
Move global.json up to root of repo, change SDK ver to 2.2.100
Change .net core sdk in dockerfile for kokoro to ver 2.2.100
* Re-add curl install
* Change all exe target to 2.1
* Fix incorrect versions in global.json and Dockerfile
* Downgrade version to 2.1 to match exe targets
* introduce separate testing Dockerfile for C#
* revert changes to the shared Dockerfile
* use netcoreapp2.1 for C# conformance tests
* use language specific dockerfile for testing C#
* Edit compatibility tests script to use parameters instead of file copies
* install dotnet SDK on windows before running the tests
* update csharp_EXTRA_DIST
* fix macos build by changing xcode version
* add comments
* fix benchmark build for mac
* fix for gem option and install npm
* add test for node and npm
* fix node
* fix for node
* another attempts to fix node
* another attempts
* clean up
* fix macos build by changing xcode version
* add comments
* fix benchmark build for mac
* fix for gem option and install npm
* add test for node and npm
* fix node
* fix for node
* another attempts to fix node
* another attempts
* clean up
* Add several fixes for python toolchain
* Fix versin regex
* Make script exit on error
* Fix version regex
* Fix version regex
* Fix version regex
* Fix version regex
* Make test run on the current commit
* Fix test
* Fix test
* Use git to retrieve current commit
* Fix tests
* Fix tests
* Also make linux and mac work on the current commit
* Fix test
* Use gnu for ruby build because strptime is provided by posix
* Move option to extconf.rb
* Remove unused code in Rakefile
* Add config files for kokoro test
* Use gnu 11
* Define _XOPEN_SOURCE
* Add gnu11 option
* Remove XOPEN
* Try base_cc_flags
* Try config_options
* Move time.h to top
* Try -D_XOPEN_SOURCE=700
* Define XOPEN_SOURCE directly
* Try extconf.rb
* Try CFLAGS
* Try ext.cross_config_options
* Make mac ruby release job fail on error
* Try again
* Try define _XOPEN_SOURCE in extconf.rb
* Try again
* Define __USE_XOPEN
* Remove 2.6.0
* No mingw
* Throw error on mingw
* Remove XOPEN_SOURCE in upb
* Add back mingw
* Remove comment
* Fix python release build.
* Separate config.sh by platform
* Use KOKORO_JOR_NAME to determine the BUILD_COMMIT.
* Use -std=c++14 on MacOS so -latomic can be used.
* Fix python release build.
* Separate config.sh by platform
* Use KOKORO_JOR_NAME to determine the BUILD_COMMIT.
* Use -std=c++14 on MacOS so -latomic can be used.
* Add ruby 2.6 gem build for linux
* Add docker hub organization
* Add ruby2.6 in cross compile targets
* Fix tests
* Check mac version
* No need to install php in preparation for mac
* Add ruby 2.6 test
* Fix broken tests
* Fix compatibility test
* Fix bundler version
* Use new docker image
* Fix broken test
* Use new docker image in ruby26 test
* Install ruby for mac
* Rebuild python docker image
* Update docker image
* Change call to build_and_run_docker.sh
* Set up python tests for different versions
* Fix comments
* Inherit from message instead of implement
When regestering class (implmenets other class) during MINIT, zend_class_implements
would call zend_class_entry->interface_gets_implemented(). In PHP-7.3 interface_gets_implemented shares the same location with create_object.
However, during MINIT, the global object storeage hasn't been initialized. And thus, caused segment fault in php 7.3.
* Use zend_string_init where interned string may be the value.
zend_string_dup will keep using the existing interned string.
In php 7.3, interned string cannot be destroyed from user's code.
* Uncommment debug code
* Use latest phpunit for each php versions
* Revert change in Dockerfile
* Update php test to use the new docker image
* Update composer
* Change docker organization
* Update phpunit
* Debug phpunit
* Store phpunit into bin dir in docker image
* Install valgrind to docker
* Fix compatibility test
* Remove generated_service_test from compatibility c extension test
* Update 32bit php test to the new docker image
* Install bison
* Fix build.sh
* Fix DOCKERIMAGE_PREFIX
* Fix basename
* Add comment to build_and_run_docker2.sh
* Remove commented code
* Fix comments
* Add kokoro build for python source package
* Use libc++ for xcode 10 (#5303)
The xcode 10 removes the deprecated libstdc++ library. We could set
"MACOSX_DEPLOYMENT_TARGET" to "10.9" to use libc++ instead.
* Add python 3.7 build
* Add build for python 3.7 on linux and windows
* Remove unused source build
* Add comment
* Fix $MACOSX_DEPLOYMENT_TARGET mismatch
* Fix MACOSX_DEPLOYMENT_TARGET mismatch
* Add missing import for sysconfig
* Add missing imports
Changes:
1. Remove stuff no longer needed. Lots of the heavy lifting were there
because we were running our own jenkins cluster and had to manage all
the test logs ourselves. Now they are useless.
2. Change "-j2" to "-j4" to speed up the test a little bit. Kokoro
machines have 4 logic CPUs according to their spec.
This was fairly straightforward using the existing build-protoc.sh
script. The only problem I ran into was that the x86 Docker builds
create output directories owned by root, which caused some permission
issues. Fortunately it was easy to get around that just by doing those
Docker builds last.
* Install rake compiler
* Add kokoro config to build ruby gem on linux
* Rename from linix to linux
* Fix prepare_build.sh name
* Clean up
* Install bundler
* Install bundler
* Use c99 in order to build gem on mingw-32 on ruby 2.0.0
See https://github.com/rake-compiler/rake-compiler-dock/issues/4
* Move c99 config to extcofig.rb
This configuration builds both 32-bit and 64-bit binaries for Mac OS X.
One thing I had to change was to increase our minimum supported version
for 10.7 to 10.9, because 10.9 (Mavericks) appears to be the earliest
version supporting C++11.
This will allow SourceLink as per #4179, and mean that we can use C#
7.0 language features in the library (but not in generated code).
This does not affect which platforms we're *targeting*, so end users
won't see any difference.
It would be nice to update to 2.1.4, but AppVeyor's "Visual Studio
2017" environment is only 2.0.3.
