This will allow us to experiment with (and subsequently migrate to)
changes to the generated API, possibly incompatible ones.
This change should be a no-op for current builds, as there is only
a single version of Sandboxed API.
PiperOrigin-RevId: 438003314
Change-Id: Ia23ea4360bee0227692d9f5220ab20d85f089ba7
This change merges the internal version of `sapi.bzl` with the external version again:
- Add more docstrings to the various macros
- Skip creation of `.isystem` file, get info from toolchain instead
PiperOrigin-RevId: 437730588
Change-Id: I6f670d32e3d7177a6a160fd24cbee6f8f3ca9503
Use [`direct_headers`](https://bazel.build/rules/lib/CompilationContext#direct_headers)
from the Bazel/Blaze compilation context instead of _all_ transitive headers.
For the clang based generator, this means we don't try to parse
`textual_headers`, which will fail (they are by definition not
stand-alone, after all).
PiperOrigin-RevId: 431899423
Change-Id: I7a9dfa0dd93eba14b506b0e7ca6db3ed59b55dd6
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
Build macros in earlier versions of Bazel (pre-1.0) needed to specify
targets in a different format, depending from where they were
included/expanded at build time.
For example, a `sapi_library()` macro invocation in one of the directories
under `examples`, always needed to depend on the SAPI main library as
`//sandboxed_api:sapi`. When using SAPI from another Bazel project, the
same macro would have needed to depend on
`@com_google_sandboxed_api//sandboxed_api:sapi`. The `sapi_library()`
macro was thus checking the repository name and conditionally changed
the dependencies. This approach is brittle and as of Bazel 3.1.0 no
longer works.
This CL simple removes the conditional prefix and unconditionally uses
`@com_google_sandboxed_api`.
Tested on Bazel 1.2.1, 2.2.0 and 3.1.0
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
Since the interface generator is invoked via a Bazel macro, it will be
expanded in the embedding context of the project using SAPI, so package access
needs to go through the full workspace root @com_google_sandboxed_api.
This change also modifies the CMakeLists.txt accordingly, as the "external"
subdirectory is no longer needed/wanted.
PiperOrigin-RevId: 255918784
Change-Id: I052c687509f65fef7f011a9d1a074a171595330f
Starting with Bazel 0.27.0 --incompatible_depset_is_not_iterable became the
default.
Fixes#27
PiperOrigin-RevId: 254703981
Change-Id: I727e4b1c6a907c8794a00f61646c13ad8d4437b7