- Extract dependent types directly from the Clang AST and re-serialize
back into compilable code
- Collect types and emit diagnostics
- Format generated code
Signed-off-by: Christian Blichmann <mail@blichmann.eu>
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>
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
* Move add_sapi_library() into a build defs file
* Override protobuf_generate_cpp() instead of naming it sapi_protobuf_generate_cpp()
* Factor out inclusion/find_package() calls of external dependencies
PiperOrigin-RevId: 258133422
Change-Id: Ibdbab0c735157eac0ed6122ab78f9d583c6905cc
* 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
This change adds CMake targets for the actual Sandboxed API library. On its
own, this is not very useful, as there is no CMake equivalent to the
sapi_library() rule, yet. This will be worked on next.
PiperOrigin-RevId: 257177362
Change-Id: Ic06c945ab534b27306021d970a83691aae2e7e60
- Add a superbuild in cmake/SuperBuild.cmake that downloads and builds
dependencies
- Builds for sandbox2/ and a its tests
- Helper CMake function to strip proto paths
- Module to find libcap
- Custom build for libunwind that wraps its symbols
- Fix environment so that CTest executes tests similar to Bazel
- Filewrapper functionality, like Bazel's cc_embed_data()
- Build forkserver with embedded binary
- Enable ASM language so that libunwind builds correctly
- Allow glog target to propagate transitively (to propagate its include dirs)
Signed-off-by: Christian Blichmann <cblichmann@google.com>
