> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reasonos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# C, C++, .NET & Protocol Buffers

> Reference for the C, C++, .NET, and Protocol Buffers rules.

This page is a concise reference for the remaining language ecosystems `rbs`
supports. Each follows the same pattern as Python and the JVM: declare a hermetic
toolchain in `WORKSPACE.rbs`, then define targets in `BUILD.rbs`.

## C

C builds use **Zig as the hermetic compiler** (`zig cc`) — no system clang or gcc
required. Rules produce real dependency wiring: headers propagate to dependents,
shared libraries are linked and made discoverable at runtime.

### Toolchain

```python theme={null}
load("@rbs//c/toolchain.rbs", "c_toolchain")

c_toolchain(
    name = "c_toolchain",
    version = "0.13.0",   # Zig version
)
```

Keep the default name `c_toolchain` — the C rules resolve the compiler by that name.

### Rules

```python theme={null}
load("@rbs//c/rules.rbs", "c_binary", "c_library", "c_shared_library")
```

| Rule               | Purpose                                                                             |
| ------------------ | ----------------------------------------------------------------------------------- |
| `c_binary`         | Compiles and links an executable with a hermetic launcher.                          |
| `c_library`        | Compiles objects; headers and objects propagate to dependents.                      |
| `c_shared_library` | Builds a `.so`/`.dylib`/`.dll` with correct soname/install-name for runtime lookup. |

Shared attributes:

| Attribute | Type        | Description                                                  |
| --------- | ----------- | ------------------------------------------------------------ |
| `srcs`    | label list  | C source files.                                              |
| `hdrs`    | label list  | Header files, propagated to dependents via include paths.    |
| `deps`    | label list  | `c_library` / `c_shared_library` targets.                    |
| `cflags`  | string list | Extra compiler flags.                                        |
| `ldflags` | string list | Extra linker flags (`c_binary` and `c_shared_library` only). |

```python theme={null}
c_binary(
    name = "hello",
    srcs = ["main.c"],
)
```

```bash theme={null}
rbs build //:hello
rbs run :hello
```

Binaries that depend on shared libraries get a launcher that sets the library search
path automatically, so `rbs run` works without any environment setup.

<Note>
  The C rules cover compiling, linking, and shared-library workflows within your
  workspace. There is no dedicated `c_test` rule and no external package registry
  integration for C — dependencies are targets you define in the workspace.
</Note>

## C++

The C++ rules are the direct counterpart of the C rules, backed by `zig c++`.

### Toolchain

```python theme={null}
load("@rbs//cxx/toolchain.rbs", "cxx_toolchain")

cxx_toolchain(
    name = "cxx_toolchain",
    version = "0.13.0",   # Zig version
)
```

Keep the default name `cxx_toolchain` — the C++ rules resolve the compiler by that
name.

### Rules

```python theme={null}
load("@rbs//cxx/rules.rbs", "cxx_binary", "cxx_library", "cxx_shared_library")
```

`cxx_binary`, `cxx_library`, and `cxx_shared_library` take the same attributes as
their C equivalents, with `cxxflags` in place of `cflags`:

| Attribute  | Type        | Description                                          |
| ---------- | ----------- | ---------------------------------------------------- |
| `srcs`     | label list  | C++ source files.                                    |
| `hdrs`     | label list  | Header files, propagated to dependents.              |
| `deps`     | label list  | `cxx_library` / `cxx_shared_library` targets.        |
| `cxxflags` | string list | Extra compiler flags.                                |
| `ldflags`  | string list | Extra linker flags (binary and shared library only). |

```python theme={null}
cxx_library(
    name = "greeter",
    srcs = ["greeter.cpp"],
    hdrs = ["greeter.h"],
)

cxx_binary(
    name = "hello",
    srcs = ["main.cpp"],
    deps = [":greeter"],
)
```

<Note>
  As with C, there is no dedicated test rule or external package registry for C++ yet.
</Note>

## .NET

`rbs` downloads the .NET SDK and builds C# applications through `dotnet publish`,
wrapping the resulting DLL in a runnable launcher.

### Toolchain

```python theme={null}
load("@rbs//dotnet/toolchain.rbs", "dotnet_toolchain")

dotnet_toolchain(name = "dotnet", version = "8.0.401")
```

Supported on macOS and Linux (amd64/arm64). Windows is not supported by this
toolchain. Keep the default name `dotnet` — the rules resolve the SDK by that name.

### Rules

```python theme={null}
load("@rbs//dotnet/rules.rbs", "dotnet_binary", "dotnet_library")
```

#### dotnet\_binary

Builds a .NET application from C# sources plus a project file. The build runs
`dotnet publish` (Release configuration), so NuGet `PackageReference` entries in your
`.csproj` are restored as part of the build.

```python theme={null}
dotnet_binary(
    name = "hello",
    srcs = ["Program.cs", "Greeter.cs", "hello.csproj"],
    assembly_name = "hello",
)
```

| Attribute       | Type       | Description                                                                               |
| --------------- | ---------- | ----------------------------------------------------------------------------------------- |
| `srcs`          | label list | C# sources; must include exactly one `.csproj`.                                           |
| `deps`          | label list | Local `dotnet_library` dependencies.                                                      |
| `assembly_name` | string     | Output assembly name (defaults to the target name); must match the `.csproj` output name. |

#### dotnet\_library

Packages C# sources (and optionally a `.csproj`) so binaries can depend on them; the
sources are compiled as part of the consuming binary's publish.

| Attribute | Type       | Description                            |
| --------- | ---------- | -------------------------------------- |
| `srcs`    | label list | C# sources and optionally a `.csproj`. |
| `deps`    | label list | Local `dotnet_library` dependencies.   |

<Note>
  .NET support is early. There is no `dotnet_test` rule yet and no standalone NuGet
  dependency rule — package dependencies are declared in your `.csproj` and restored
  during the build.
</Note>

## Protocol Buffers

Proto support is split into a shared toolchain, a language-neutral `proto_library`
rule, and per-language code-generation rules.

### Toolchain

Declare it once in `WORKSPACE.rbs`. It downloads `protoc` (v27.0) for every supported
platform along with the gRPC code-generation plugins for Java, Kotlin, Python, and Go:

```python theme={null}
load("@rbs//proto/toolchain.rbs", "proto_toolchain")

proto_toolchain()
```

### proto\_library

Declares a set of `.proto` files. Other proto libraries can be listed as `deps`, and
their files become available as imports. Load it from `@rbs//java/proto.rbs`
(the rule itself is language-neutral):

```python theme={null}
load("@rbs//java/proto.rbs", "proto_library")

proto_library(
    name = "message_proto",
    srcs = ["proto/message.proto"],
)

proto_library(
    name = "service_proto",
    srcs = ["proto/service.proto"],
    deps = [":message_proto"],
)
```

| Attribute | Type        | Description                                                |
| --------- | ----------- | ---------------------------------------------------------- |
| `srcs`    | string list | `.proto` files.                                            |
| `deps`    | label list  | Other `proto_library` targets whose files may be imported. |

### Language bindings

Each language has a generation rule that consumes a `proto_library` and produces
source code plus the runtime dependencies your targets need — the protobuf runtime is
always included, and the gRPC libraries are added when `enable_grpc = True`:

| Rule                   | Load from                |
| ---------------------- | ------------------------ |
| `java_proto_library`   | `@rbs//java/proto.rbs`   |
| `kotlin_proto_library` | `@rbs//kotlin/proto.rbs` |
| `python_proto_library` | `@rbs//python/proto.rbs` |

All three share the same attributes:

| Attribute     | Type       | Description                                         |
| ------------- | ---------- | --------------------------------------------------- |
| `proto`       | label list | The `proto_library` target to generate code from.   |
| `enable_grpc` | bool       | Also generate gRPC service stubs (default `false`). |

A complete example — proto definitions, generated code, and an application using
them:

```python theme={null}
load("@rbs//java/proto.rbs", "proto_library", "java_proto_library")
load("@rbs//java/rules.rbs", "java_library", "java_binary")

proto_library(
    name = "calculator_proto",
    srcs = ["proto/calculator.proto"],
)

java_proto_library(
    name = "calculator_java_proto",
    proto = [":calculator_proto"],
    enable_grpc = True,
)

java_library(
    name = "calculator_server_lib",
    srcs = ["src/CalculatorServiceImpl.java"],
    deps = [
        ":calculator_java_proto",
        # protobuf and gRPC runtimes are auto-included by java_proto_library
    ],
)
```

Go bindings also exist (`go_proto_library` from `@rbs//go/proto.rbs`); they are
covered with the Go rules.