The Bazel build already queries the current toolchain for its system include
directories. This change brings feature parity and is necessary for systems
with unusual include locations.
PiperOrigin-RevId: 332195812
Change-Id: Ie81d614d21e90b4bd9edf2084ef80bf0d85dd750
- 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>
Add the location of the Python 3 interpreter to the CMake cache so
that its available in the `add_sapi_library()` macro in downstream
embedding projects.
Signed-off-by: Christian Blichmann <mail@blichmann.eu>
This fixes some CMake-3.12+-isms, like `list(JOIN ...)` and setting link
properties on OBJECT libraries.
PiperOrigin-RevId: 265033725
Change-Id: I0ee1ec0e1b1097ea8226ad6fdeff794a97c2881b
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
