Instead of calling `google::InitGoogleLogging()` directly, introduce an
indirection via a new utility library. After this change, Sandboxed API
should consistently use `sapi::InitLogging()` everywhere.
For now, `sapi::InitLogging()` simply calls its glog equivalent. However,
this enables us to migrate away from the gflags dependency and use Abseil
flags. Once a follow-up change lands, `sapi::InitLogging()` will instead
initialize the google logging library with flags defined from Aseil.
Later still, once Abseil releases logging, we can then drop the glog
dependency entirely.
PiperOrigin-RevId: 445363592
Change-Id: Ia23a7dc88b8ffe65a422ea4d5233bba7bdd1303a
`BUILD_TESTING` is a CMake provided option and we should use similar naming,
just like how Abseil does it.
- `SAPI_ENABLE_TESTS` -> `SAPI_BUILD_TESTING`
- `SAPI_ENABLE_CONTRIB_TESTS` -> `SAPI_CONTRIB_BUILD_TESTING`
- `SAPI_ENABLE_EXAMPLES` -> `SAPI_BUILD_EXAMPLES`
Drive-by:
- Fix option name in GitHub action
PiperOrigin-RevId: 443305932
Change-Id: Ice2b42be1229a0f9ae7c2ceda9ce87187baf22c4
Including the `CTest` modules ensures that the `BUILD_TESTING` option is
defined and automatically calls `enable_testing()` if needed. It does not
change the default or introduce any dependencies on its own.
This follows what Abseil already does in their top-level `CMakeLists.txt`.
PiperOrigin-RevId: 443305646
Change-Id: If067c17470f497437c7748aab4aab5227c26e84f
Bazel's `Runfiles::Create()` does not actually need a value for `argv0` in
order to find runfiles for the current `cc_binary`.
- Rename `runfiles.cc` to `runfiles_nobazel.cc`
PiperOrigin-RevId: 443061178
Change-Id: I31e16d69d24aecbc403f9407fc08c615bb1e8f9f
We have a SAPI_ASSERT_OK_AND_ASSIGN which corespondents to
SAPI_ASSIGN_OR_RETURN.
We also have SAPI_RETURN_IF_ERROR but we don't have a coresponding
macro for ASSERT.
I think that this completes the API and makes writting tests a little
bit simpler.
Instead of C++17 structured bindings, use a plain `const auto&` and annotate
arguments with comments instead.
We still support Clang 6.0, as that is the compiler that ships with Ubuntu
18.04 LTS by default.
PiperOrigin-RevId: 428016214
Change-Id: I3a43b2d47c6825ac4425d22018750282cfe23c1b
Plain `readdir` is preferred and while not (yet) specified in POSIX it is thread-safe for different directory streams in popular implementations.
PiperOrigin-RevId: 423321528
Change-Id: I4e1e842f338ff7d690c36e7f699b2f3637609524
Bazel readily enforces header visiblity for each target, CMake is more lenient.
PiperOrigin-RevId: 355407845
Change-Id: Ic59fa2162db8456d4c5cf4205c0fe42cc79874a9
This change should make it less confusing where utility code comes from.
Having it in two places made sense when we were debating whether to publish
Sandbox2 separately, but not any longer.
Follow-up changes will move `sandbox2/util.h` and rename the remaining
`sandbox2/util` folder.
PiperOrigin-RevId: 351601640
Change-Id: I6256845261f610e590c25e2c59851cc51da2d778
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
The defined raw logging macros should be compatible with Abseil and
we can remove our version once Abseil releases theirs.
PiperOrigin-RevId: 347354273
Change-Id: I178a89cfd2e19bcd707a06fa9dfd7b767e2b654b
We need to add the `oss-internship-2020` and `examples/hello_sapi`
directories to `.bazelignore`, so that `bazel build ...` works on a clean
working copy. This is because the Bazel builds in these directories use their
own `WORKSPACE.bazel` and this does not nest well, leading to all kinds of
hard to debug errors.
PiperOrigin-RevId: 333728800
Change-Id: Ie2e68dd39bf6f8eb21af29d8ae3ae12971b408db
This removes our own fork of `absl::StatusOr<>`. Sandboxed API still includes
a custom matcher for Googletest, as that is not open source yet. For
compatibility, the `statusor.h` header is still retained and now aliases
`sapi::StatusOr<>` to `absl::StatusOr<>`.
PiperOrigin-RevId: 329916309
Change-Id: I0544b73a9e312dce499bc4128c28457e04ab9929
Fixes some template issues that could lead to code not compiling when it
otherwise should.
PiperOrigin-RevId: 308809964
Change-Id: I9f2f9d4aff5f1a9cb967fb705a86fd7f49114f7a
The underlying issue is with a Copybara transform and the internal Blaze BUILD file.
PiperOrigin-RevId: 308787839
Change-Id: I32af664b3eac4c925d39f50b967756198eff23f3
Note: This intentionally omits perfect-forwarding value assignments. This
avoids overly complex template expressions. The regular assignments are still
efficient.
PiperOrigin-RevId: 304159053
Change-Id: I3460f46ca5779a0619cf90ae22625de8fad7669c
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>
