opal-cpp/MODULE.bazel at main · muchq/opal-cpp · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
# The bzlmod module version stays 0.0.0 until the module is published to the
# Bazel Central Registry (deferred, PLAN Phase 6); consumers override the source
# with git_override/local_path_override, which ignores this value. The product
# version consumers actually observe is opal::Version() / the client
# User-Agent ("0.2.0"). See docs/versioning.md.
module(
    name = "opal_cpp",
    version = "0.0.0",
)

bazel_dep(name = "platforms", version = "1.1.0")
bazel_dep(name = "rules_cc", version = "0.2.22")
bazel_dep(name = "googletest", version = "1.18.0.bcr.1")
bazel_dep(name = "google_benchmark", version = "1.9.5")
bazel_dep(name = "boost.asio", version = "1.90.0.bcr.1")

# TLS for the Beast transports (ADR-0007). The asio SSL implementation is
# compiled in runtime/src/http/beast_src.cc against BoringSSL directly, so
# consumers need no @boost.asio//:ssl flag. boringssl tracks what boost.asio
# 1.90 requires — pinned explicitly so the security-sensitive dependency
# bumps deliberately, never as an MVS side effect.
bazel_dep(name = "boringssl", version = "0.20260813.0")
bazel_dep(name = "boost.beast", version = "1.90.0.bcr.1")
bazel_dep(name = "nlohmann_json", version = "3.12.0.bcr.2")
bazel_dep(name = "zlib", version = "1.3.2")

bazel_dep(name = "rules_shell", version = "0.8.0", dev_dependency = True)
bazel_dep(name = "rules_testing", version = "0.9.0", dev_dependency = True)

# Hermetic LLVM toolchain with libc++ — the linux clang+libc++ matrix cell
# (CI's --config=llvm job) and the setup serious Bazel consumers run
# (a hermetic clang + parse_headers is exactly the environment that caught the
# boost.context std::result_of gap). Dev-only and unregistered by default:
# the CI job selects it with --extra_toolchains, so ordinary builds keep the
# autodetected toolchain. libc++ is this toolchain's default stdlib.
#
# hermetic-llvm (BCR module "llvm") rather than toolchains_llvm: it is
# zero-sysroot, so the cell compiles against Bazel-supplied glibc/kernel
# headers and libc++ instead of the runner's /usr/include, and the LLVM
# version rides the module rather than a pinned release tarball.
bazel_dep(name = "llvm", version = "0.8.19", dev_dependency = True)

# The code generator runs inside the build graph as a hermetic Java action
# (bazel/defs.bzl); rules_jvm_external pins its Smithy dependencies.
# rules_java tracks what Bazel 9's own bazel_tools already forces into the
# resolved graph — a lower pin here only buys the check_direct_dependencies
# warning on every invocation.
bazel_dep(name = "rules_java", version = "9.9.0")
bazel_dep(name = "rules_jvm_external", version = "7.1")

maven = use_extension("@rules_jvm_external//:extensions.bzl", "maven")
maven.install(
    name = "smithy_cpp_codegen_maven",
    artifacts = [
        # alloy#simpleRestJson — the vendor-neutral REST/JSON protocol trait.
        "com.disneystreaming.alloy:alloy-core:0.3.40",
        "software.amazon.smithy:smithy-build:1.73.0",
        "software.amazon.smithy:smithy-codegen-core:1.73.0",
        "software.amazon.smithy:smithy-protocol-test-traits:1.73.0",
        "software.amazon.smithy:smithy-protocol-traits:1.73.0",
    ],
    lock_file = "//:maven_install.json",
    repositories = ["https://repo1.maven.org/maven2"],
)
use_repo(maven, "smithy_cpp_codegen_maven")