In some platforms ${CMAKE_INSTALL_LIBDIR} expands to `lib64`. The libraries
are correctly installed in that directory, but the RPATH is set to point to
`$ORIGIN/../lib`, where it should be `$ORIGIN/../lib64`.
* 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
* Down-integrate internal changes to github.
* fix python conformance test
* fix csharp conformance test
* add back java map_lite_test.proto's optimize for option
* fix php conformance test
This reverts commit 93f6b67eb2.
Protoc adds already the relative path to the output directory.
Therefore, we have to remove this again from the output directory
to prevent adding it twice.
Without this fix, protobuf_generate() sets the variable _generated_srcs to
${protobuf_generate_PROTOC_OUT_DIR}/${_rel_dir}/${_basename}${_ext}
but generates the files in
${protobuf_generate_PROTOC_OUT_DIR}/${_basename}${_ext}
* CMake: Add comment for CMP0048
* CMake: osx use @rpath/ as target's install name (CMP0042)
On MacoS library should use @rpath/ as prefix path instead of absolute build path
e.g. otool -L libprotobuf.dylib
libprotobuf.dylib:
@rpath/libprotobuf.dylib (...)
...
* CMake: add rpath to target for LINUX and APPLE
For google/or-tools, on windows, we need to use `import "google/protobuf/wrappers.proto";` since we want "optional" int64 and in version3 POD get default value...
-> so we use "google.protobuf.Int64Value" since 0 is a valid value and different from "not set" for our use case.