CMake: allow building and installing libprotobuf-lite without libprotobuf

## Summary I would like to propose CMake support for building, installing, and exporting `protobuf::libprotobuf-lite` without also building `libprotobuf`, while keeping the current default behavior unchanged. I am not proposing to change the default build. I am asking whether this build-system direction would be acceptable before preparing a PR. This is intended for downstream projects that generate C++ sources from `.proto` files using: ```proto option optimize_for = LITE_RUNTIME; ``` In that setup, `protoc` is a host/build tool, but the target package only needs to link `protobuf::libprotobuf-lite`. ## Current behavior The current CMake option `protobuf_BUILD_PROTOBUF_BINARIES` groups both runtime libraries together: - `libprotobuf-lite` - `libprotobuf` This means package-manager builds and downstream target builds generally need to compile and install the full runtime even when the target consumer only uses `protobuf::libprotobuf-lite`. ## Proposed CMake options Add separate runtime library options, both defaulting to `ON`: ```cmake option(protobuf_BUILD_LIBPROTOBUF "Build libprotobuf" ON) option(protobuf_BUILD_LIBPROTOBUF_LITE "Build libprotobuf-lite" ON) ``` With those defaults, existing CMake behavior remains intact. A normal build continues to build both runtime libraries unless a caller explicitly opts out. For a lite-only runtime install, the tested configuration was: ```cmake -Dprotobuf_BUILD_TESTS=OFF -Dprotobuf_BUILD_CONFORMANCE=OFF -Dprotobuf_BUILD_EXAMPLES=OFF -Dprotobuf_BUILD_PROTOC_BINARIES=OFF -Dprotobuf_BUILD_LIBPROTOC=OFF -Dprotobuf_BUILD_LIBUPB=OFF -Dprotobuf_BUILD_LIBPROTOBUF=OFF -Dprotobuf_BUILD_LIBPROTOBUF_LITE=ON ``` The primary consumer contract is CONFIG mode: ```cmake find_package(protobuf CONFIG REQUIRED) target_link_libraries(app PRIVATE protobuf::libprotobuf-lite) ``` Legacy MODULE-compatible variables can remain best-effort for this mode. Consumers that require the full-runtime `${Protobuf_LIBRARIES}` variable are out of scope for a lite-only target package. ## Proof-of-concept validation I implemented a local CMake PoC limited to CMake/build/install/export/pkg-config logic. It does not modify Bazel files, does not modify the C++ runtime, and does not attempt to minimize or prune installed headers. Validation was run on Windows with the CMake default Visual Studio generator. Ninja was requested but was not available in the environment, so the automation fell back to the CMake default generator. Measured results: | 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 lite-only configure step was slower in this local run, but the build step dominated the total time and dropped from `508.063s` to `55.648s`. Consumer CMake test: PASS. The default install contained: - `libprotobuf` - `libprotobuf-lite` - `libprotoc` - `protoc` - `libupb` - `protobuf.pc` - `protobuf-lite.pc` The lite-only install contained: - `libprotobuf-lite` - `protobuf-lite.pc` The lite-only install did not contain: - `libprotobuf` - `libprotoc` - `protoc` - `libupb` - `protobuf.pc` The lite-only CMake package exported `protobuf::libprotobuf-lite`, did not export `protobuf::libprotobuf`, and `find_package(protobuf CONFIG REQUIRED)` worked for a minimal consumer linking only `protobuf::libprotobuf-lite`. ## Notes from the PoC - Defaults remain intact. - Install/export must be target-aware so `protobuf-targets.cmake` does not reference targets that were not built. - In the PoC, `protobuf-lite.pc` is only generated/installed when `libprotobuf-lite` exists. - In the PoC, `protobuf.pc` is only generated/installed when `libprotobuf` exists. - The current CMake `libprotoc` target links `libupb`, so the PoC rejected `protobuf_BUILD_LIBPROTOC=ON` with `protobuf_BUILD_LIBUPB=OFF`. - CONFIG mode is the main acceptance criterion; MODULE mode can be treated as compatibility best-effort. ## Related issues - #20539 discusses default build time and lack of knobs to exclude unneeded build components. - #18307 discusses CMake install/export problems caused by `libupb` being hard-bound. This request is narrower than both: it specifically asks for a target-package mode where `protobuf::libprotobuf-lite` can be built, installed, and exported without `libprotobuf`. ## Reference PoC The local PoC commit is available here for reference: https://github.com/dudantas/protobuf/commit/d90e663b1c3d1f90ff2b4caf9ec3c8b2bf5f583b ## Question Would a PR in this direction be acceptable if it preserves the current defaults and includes validation that CONFIG-mode consumers can use `protobuf::libprotobuf-lite` when `protobuf::libprotobuf` is absent?