`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
When building contrib libraries as a Sandboxed API super-project or when
building Sandboxed API as a sub-project, CMake may not include all files
when writing a `compile_commands.json`, leading to missing include paths
for the libtooling interface generator.
This change sets `CMAKE_EXPORT_COMPILE_COMMANDS` as a cache variable so
that it persists across project boundaries. Writing compilation databases,
even when they are otherwise unused, is harmless.
PiperOrigin-RevId: 439820022
Change-Id: Ice96e78cf41fff5792aa0a8734f1ccf80f541e4c
The corresponding command-line option `sapi_isystem` will be ignored for
compatibility.
PiperOrigin-RevId: 439806387
Change-Id: I8ad6d7feed2fba5fca9940281f03cfc757ada5be
The generated `compile_commands.json` contains everything that the interface
generator needs.
PiperOrigin-RevId: 439800377
Change-Id: I5b364edc20eaae9554ce10a96caa3559fb780210
This adds basic workflows to build jsonnet and pffft, to be expanded later.
PiperOrigin-RevId: 439564724
Change-Id: Ia408545f8badd70b7aeeddb7a789d0d267cd0652
- Set the correct cache path, previously cache was ineffective
- Build in `${GITHUB_WORKSPACE}/build` sub-directory
- Update `actions/cache` to `v3`
- Reformat build steps
- Use CMake's `-S` and `-B` options to specify source and build directories
PiperOrigin-RevId: 439560955
Change-Id: I6b07fa4e3a6416725fa1d3d2b7174a4186648033
This makes `sapi_library()` more compatible with Bazel's native `cc_library()`
rule.
PiperOrigin-RevId: 439512659
Change-Id: If731f600d56db56f78d2897e0c41a200daa93b75
This should fix the build on Debian 10 with LLVM 11.
- Keep order of files to look up in `ls` invocation
- Use `--start-group`/`--end-group` linker options
- Drive-by: use `splitlines()` instead of manual `split("\n")[:-1]`
PiperOrigin-RevId: 439248079
Change-Id: I919bb292ac8a5f514431aa004345f1c6478b1cc9
This change introduces an experimental `generator_version` attribute to the
`sapi_library()` rule. Version `1` will select the current interface
generator, which is based on libclang and Python. Setting the attribute to
version `2`, will select the newer interface generator written in C++ that
uses a full clang compiler frontend for parsing. Both emit equivalent header
output, differences in parsing and/or edge cases notwithstanding.
The default, as of now, is still the old version `1` generator.
Note: CMake allows to select the new interface generator globally by setting
`SAPI_ENABLE_GENERATOR`.
PiperOrigin-RevId: 438765013
Change-Id: I69c49a6bcf1751724edb0bce5c3b2beea2097138
This should make the build much faster when compiling the new interface
generator on BazelCI.
PiperOrigin-RevId: 438762508
Change-Id: Ie7efe14d7bd2b14d58cbbb7865b36751918d9145
This adds a workspace rule that inspects the current system first and
downloads a suitable version of LLVM/Clang from GitHub if it can't
find one. In the latter case, the necessary parts are build from source,
which can take a while (~10-15m, depending on the build machine).
In order to be found, LLVM/Clang system libraries must be version 11
or higher. On Debian/Ubuntu, install `llvm-13-dev` and `libclang-13-dev`.
The new `llvm_config.bzl` implements this logic. It is loosely based on
upstream's https://github.com/llvm/llvm-project/blob/main/utils/bazel/configure.bzl.
Note that due to the way Bazel separates local repositories, we have to
duplictate some of this code.
PiperOrigin-RevId: 438759950
Change-Id: Ia65f473b4cdef6507e3816bf09794ea10963d87a
Update `.bazelrc` for local (host target) tooling. This is a necessary
precondition to compile the new interface generator with Bazel.
PiperOrigin-RevId: 438541332
Change-Id: I9341ee4d1f4434c1d083e0d49774c61f9ebd7d7b
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
This fixes the main issue (#118) with stack traces on Fedora, which uses a
`/lib64` and `/usr/lib64`.
PiperOrigin-RevId: 437717858
Change-Id: I6986aa84c2be57ae1d9f8d0cb9b508768d27f1c1
--
2019d66f52eeb31d0de583f2e2f0364192b706d4 by Demi Marie Obenour <demi@invisiblethingslab.com>:
Fix uriparser build
A path was wrong.
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/sandboxed-api/pull/150 from DemiMarie:fix-uriparser-build 2019d66f52eeb31d0de583f2e2f0364192b706d4
PiperOrigin-RevId: 435587012
Change-Id: I70e392f86f796c5ebeccc8e920110aecb8c40b42
