Guidance: acceptable vcpkg model for upstream Protobuf lite-only runtime builds?

[Eduardo Dantas (dudantas)]

Context

There is an upstream Protobuf discussion about supporting a narrowly constrained CMake lite-only runtime mode:

• CMake: allow building and installing libprotobuf-lite without libprotobuf protocolbuffers/protobuf#27231

Based on that discussion, I opened a draft upstream PR implementing the narrow variant requested by the Protobuf maintainer:

• cmake: support narrowly constrained lite-only runtime builds protocolbuffers/protobuf#27407

The upstream maintainer agreed that the use case makes enough sense to review a PR, while also noting concern about expanding the CMake option matrix. The PR is intentionally strict and does not try to support every possible CMake combination.

The intended upstream shape is:

• defaults unchanged;
• no Bazel/runtime C++ changes;
• no header pruning;
• only one new CMake knob:

  option(protobuf_BUILD_LIBPROTOBUF "Build libprotobuf" ON)

• target-side lite-only only when:
  • protobuf_BUILD_LIBPROTOBUF=OFF
  • protobuf_BUILD_PROTOC_BINARIES=OFF
  • protobuf_BUILD_LIBPROTOC=OFF
  • protobuf_BUILD_LIBUPB=OFF
  • tests/conformance/examples are OFF;
• libprotobuf-lite remains built/exported;
• libprotobuf, libprotoc, protoc, and libupb are not built/exported in lite-only mode;
• CONFIG mode exports only targets that were actually built;
• validation focused on:

  find_package(protobuf CONFIG REQUIRED)
  target_link_libraries(app PRIVATE protobuf::libprotobuf-lite)

The use case is package-manager/cross-build oriented:

• protoc is supplied by a separate host build;
• generated .proto files use:

  option optimize_for = LITE_RUNTIME;

• the target package only links protobuf::libprotobuf-lite;
• target libprotobuf, libprotoc, protoc, and libupb are not needed.

The local upstream PoC measured:

Variant	Configure	Build	Install	Install size
Default	21.299s	508.063s	7.699s	113754 KB
Lite-only	49.902s	55.648s	4.363s	21579 KB

The draft upstream PR was validated locally with:

• default build/install;
• lite-only build/install;
• external CONFIG-mode consumer using protobuf::libprotobuf-lite;
• invalid configuration checks for unsupported lite-only combinations.

There is also a separate vcpkg PR related to reducing target-side libprotoc/libupb installs:

• [protobuf] Make target libprotoc opt-in for non-native builds #51545

That PR is independent from the full-vs-lite runtime question. It only addresses target libprotoc/libupb.

---

Question

If upstream Protobuf accepts this narrowly constrained lite-only runtime mode, what packaging model would be considered acceptable for vcpkg's curated registry?

I see a few possible directions, but I am unsure which one best aligns with vcpkg policy and maintainer expectations.

Option A — overlay/custom registry only

Projects that need target-side lite-only Protobuf keep using overlays/custom registries and pass the upstream CMake option there.

This is the safest policy-wise, but downstream projects continue maintaining custom ports.

Option B — default-on full-runtime feature

Keep current behavior as the default feature set:

"default-features": ["full-runtime"]

Then:

• protobuf keeps current behavior;
• protobuf[core] could become target-side lite-only.

However, I am not sure whether using a default feature for the full runtime/API surface would be considered acceptable.

Option C — lite-runtime feature

A feature such as:

"features": {
  "lite-runtime": { ... }
}

would effectively disable libprotobuf, so I assume this may conflict with vcpkg's additive feature model.

Option D — separate protobuf-lite port

This seems problematic because it would likely conflict with protobuf on:

• headers;
• CMake config files;
• pkg-config files;
• protobuf:: targets.

So I assume this is not desirable for the curated registry, but I would appreciate confirmation.

---

What I am asking

Before I spend time preparing a vcpkg-side implementation, I would like maintainer guidance on:

1. Would vcpkg accept any curated-registry model for target-side lite-only Protobuf if upstream accepts the narrow CMake mode?
2. Is a default-on full-runtime feature acceptable in this case, or would that violate default-feature guidance because it controls public API/binary surface?
3. Is a separate protobuf-lite port categorically unacceptable because of file/target conflicts?
4. Should this remain an overlay/custom-registry-only use case even if upstream Protobuf supports it?
5. If there is an acceptable approach, what manifest/feature shape would you prefer?

[Eduardo Dantas (dudantas)]

Billy O'Neal (@BillyONeal) sorry for the direct ping, but you reviewed the related protobuf vcpkg change in #51545, so I think you may be the right person to sanity-check this.

Upstream Protobuf has now accepted and landed the narrowly constrained lite-only CMake mode:
protocolbuffers/protobuf@7c09017

Before I open any vcpkg PR, I would like to avoid proposing a model that conflicts with vcpkg's feature policy. Is this expected to remain overlay/custom-registry-only, or is there an acceptable curated-registry model once this lands in a Protobuf release?

[Eduardo Dantas (dudantas)]

Small update: Protobuf v36.0-rc1 now includes the upstream lite-only CMake support:
https://github.com/protocolbuffers/protobuf/releases/tag/v36.0-rc1

I am not planning to open a vcpkg PR against an RC. My current plan is to wait for the stable v36.0 release, then submit a normal protobuf version update first. If maintainers have a preferred model for exposing the lite-only runtime in vcpkg, I can align the follow-up PR with that guidance.