This allows resource-constrained environments to benefit from the
space savings of dynamic linking. This is not meant to be used in
the general case.
PiperOrigin-RevId: 347398828
Change-Id: Ia634959148a31159878f48c44255dd733424a2b8
When embedding SAPI in an external CMake project, the version of
`protobuf_generate_cpp` that we lifted from upstream protobuf produces
the wrong generated file paths.
For example, given this project structure:
```
/parent/
+-- myproject/
+-- myproject_build/ <- CMake build directory
+-- sandboxed-api/ <- Checkout from GitHub
```
And a CMake file in `myproject/CMakeLists.txt` that embeds SAPI like
this:
```
cmake_minimum_required(VERSION 3.12)
project(SandboxedTest LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
add_subdirectory(
${PROJECT_SOURCE_DIR}/../sandboxed-api
${PROJECT_BINARY_DIR}/sandboxed-api
)
```
Then `protobuf_generate_cpp` correctly invokes the protoc compiler to
generate
`/parent/myproject_build/sandboxed-api/sandboxed_api/proto_arg.proto.pb.cc'.
However, the path of the generated source file that is passed to the C++
compiler will be
`/parent/myproject_build/sandboxed-api/sandboxed_api/../../myproject_build/sandboxed-api/sandboxed_api/proto_arg.pb.cc`.
Note the duplicated project build directory component in the
canonicalized version:
`/parent/myproject_build/myproject_build/sandboxed-api/sandboxed_api/proto_arg.pb.cc`.
This change simple omits the computation of any relative file paths and
simply uses `_pb_PROTOC_OUT_DIR` which defauls to
`CMAKE_CURRENT_BINARY_DIR`, which should always contain the correct
path.
Signed-off-by: Christian Blichmann <mail@blichmann.eu>
These where inadvertently introduced in an internal cleanup change.
This change also removes a C++17-ism in var_proto.h. To make things easier for
downstream projects, we should stick to C++11 for the time being.
PiperOrigin-RevId: 271117700
Change-Id: I4eaacec88be16e1a561d3f77a61acce0a1af0b9d
This fixes some CMake-3.12+-isms, like `list(JOIN ...)` and setting link
properties on OBJECT libraries.
PiperOrigin-RevId: 265033725
Change-Id: I0ee1ec0e1b1097ea8226ad6fdeff794a97c2881b
The temporary solution for binaries/tests that fully statically linked is to
link against `gflags` using `-Wl,--whole-archive`. This will no longer be
necessary, once Abseil ships with logging. Then we can (finally) use Abseil
flags and use a logging library that does not depend on a different flags
library.
PiperOrigin-RevId: 260705702
Change-Id: I8562faaff59f9c3e0e1d331186d2806d387438fb
This change moves away from a classical superbuild which downloads and builds
at build time. Instead, we now follow a "Fetch Content" workflow (available as
FetchContent in CMake 3.11+) and download dependencies at config time.
Rationale: Superbuild projects have the disadvantage that projects cannot
directly access their individual declared targets. This is not a problem with
regular libraries, as those are usually/supposed to be installed. With
Sandboxed API, this is not desirable, as it has dependencies like Abseil and
glog, which are almost always consumed by including their source tree using
add_subdirectory().
Fixes#10 and makes external embedding easier.
PiperOrigin-RevId: 260129870
Change-Id: I70f295f29a6e4fc8c330512c94b01ef10c017166
* Implement add_sapi_library() similar to the Bazel rule
* Fix SuperBuild so that glog properly depends on gflags (needed for --logtostderr)
* Raise minimum required version of CMake to 3.10 (Ubuntu 18.04 LTS)
* Update sum sandbox policy to allow to get IDs and PIDs
PiperOrigin-RevId: 258124160
Change-Id: I64c2f8b27a3e842874adca9100bfce20a2b74f17
