Add Bazel build support - #37
Open
BYVoid wants to merge 1 commit into
Open
Conversation
This was referenced Aug 27, 2026
fmeum
pushed a commit
to bazelbuild/bazel-central-registry
that referenced
this pull request
Aug 27, 2026
Adds an OpenMP option to the libsais overlay, which 2.10.4 was missing. In 2.10.4 the overlay had no counterpart to the `LIBSAIS_USE_OPENMP` option of the upstream CMake build, so enabling OpenMP required consumers to pass global `--copt`/`--linkopt` flags, which apply to every dependency in the build. This version adds the flag to the overlay instead: ```sh bazel build <your target> --@libsais//:openmp ``` It adds `-fopenmp` (`/openmp` on MSVC and clang-cl) to the compile and link commands and defines `LIBSAIS_OPENMP`. Upstream declares that definition as `PUBLIC` in CMake, so the overlay uses the propagating `defines` attribute: the `*_omp` declarations in the public headers are guarded by it, and dependents need to see them. It is off by default, as upstream is. The tests now also run the `*_omp` entry point with two threads when the flag is set, and a `verify_targets_openmp` task builds and tests everything with `--@libsais//:openmp`. That task skips macOS, since Apple clang ships without OpenMP support. libsais only uses `barrier`, `master`, `parallel num_threads` and `parallel for schedule(static)`, all of which are within the OpenMP 2.0 subset that MSVC implements, so Windows is covered. Apart from that, the archive and the four targets are unchanged from 2.10.4. The new `bazel_skylib` dependency is used for the `bool_flag` and the `config_setting_group`s that combine the flag with the compiler. Verified with `bazel test @libsais//...` against a local registry, and with `bazel cquery --output=build` with and without the flag, to confirm the flags and the define are applied only when it is set. The OpenMP configuration itself cannot be built on this machine, so the `verify_targets_openmp` task is the first real check of it; the tests' OpenMP branch was at least compiled here with `-DLIBSAIS_OPENMP` against the upstream headers. The same build files are proposed upstream in IlyaGrebnov/libsais#37; if that lands, the overlay can be dropped in a future version. @bazel-io skip_check unstable_url
BYVoid
marked this pull request as ready for review
August 27, 2026 22:04
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For context: I maintain the libsais entry in the Bazel Central Registry, where versions 2.10.4 and 2.10.4.bcr.1 are already published. The registry currently carries the build files below as an overlay on top of your release tarball, and this PR offers them upstream so that they live next to the sources they build, and so the registry entry can eventually just point at your repository.
This adds an optional Bazel build alongside the existing CMake one, so that libsais can be consumed directly by Bazel projects. Nothing in
src/orinclude/is touched, and CMake users are unaffected.What is added
MODULE.bazel— declares the module aslibsaisversion 2.10.4 (would need bumping together withVERSIONandCMakeLists.txton a release).BUILD.bazel— onecc_libraryper source file:libsais,libsais16,libsais64andlibsais16x64, each exporting only its own header. The 64-bit targets depend on their 32-bit counterparts, since they delegate to them for inputs that fit intoint32_t. This is finer-grained than the single CMakelibsaistarget, so a consumer that only needs, say,libsais64does not link the 16-bit code.test/*.c— a small smoke test per variant, checking the suffix array of"banana". The repository has no test suite today, so these are only meant to make the build verifiable (bazel test //...); happy to drop them if you would rather not have atest/directory..gitignore— ignores thebazel-*convenience symlinks andMODULE.bazel.lock.README.md— a short usage section next to the CPM one.OpenMP
The
openmpbuild flag mirrors theLIBSAIS_USE_OPENMPCMake option and is off by default in the same way:It adds
-fopenmp(/openmpon MSVC and clang-cl) to the compile and link commands, and definesLIBSAIS_OPENMP. As inCMakeLists.txt, where that definition isPUBLIC, the Bazeldefinesattribute propagates it to dependents, which matters because the*_ompdeclarations in the public headers are guarded by it. When the flag is set, the tests additionally run the*_ompentry points with two threads.LIBSAIS_BUILD_SHARED_LIBhas no counterpart here: Bazel decides between static and shared linking at the consuming binary, so a per-library option is not needed.Testing
bazel test //...passes locally on macOS (Apple clang, Bazel 9.2.0). These exact files are also exercised by the registry's CI, which built and tested them with Bazel 7.x, 8.x, 9.x and rolling on Debian 11, Ubuntu 22.04, macOS and Windows, and additionally with OpenMP enabled on the three platforms whose toolchain supports it — Apple clang ships without OpenMP support. All 28 jobs passed.I am happy to adjust the layout, drop the tests or the README change, or close this if a second build system is not something you want to maintain.