LaunchDarkly monorepo for C++ SDKs.
This repository contains LaunchDarkly SDK packages which are written in C++. This includes shared libraries, used by SDKs and other tools, as well as SDKs.
Packages
| Readme | issues | tests | docs | latest release |
|---|---|---|---|---|
| libs/client-sdk | C++ Client SDK |  |
 |
On Github |
| libs/server-sdk | C++ Server SDK |  |
|
On Github |
| libs/server-sdk-redis-source | C++ Server SDK - Redis Source |  |
|
On Github |
| Shared packages | issues | tests |
|---|---|---|
| libs/common | Common |  |
| libs/internal | Internal |  |
| libs/server-sent-events | Common Server-Sent-Events |  |
Organization
| Directory | Description |
|---|---|
| .github | Contains CI and release process workflows and actions. |
| examples | Contains examples (hello-world style). |
| contract-tests | Contains contract test service. |
| cmake | Contains cmake files for importing and configuring external libraries. |
| libs | Contains library implementations. This includes libraries shared within the project as well as SDK libraries like the client-sdk. |
| scripts | Contains scripts used in the release process. |
| vendor | Contains third party source which is directly integrated into the project. Generally third party source is included through CMake using FetchContent, but some libraries require modification specific to this repository. |
Build Requirements
Dependencies
- C++17 and above
- CMake 3.19 or higher
- Ninja (if using the included build scripts)
- Boost version 1.81 or higher (excluding Boost 1.83, see note below)
- OpenSSL
[!NOTE]
Boost 1.83 is not supported due to an incompatibility in Boost.JSON. This issue appears to be resolved in versions prior and subsequent to 1.83.
Additional dependencies are fetched via CMake. For details see the cmake folder.
GoogleTest is used for testing.
For information on integrating an SDK package please refer to the SDK specific README.
CMake Usage
Various CMake options are available to customize the client/server SDK builds.
| Option | Description | Default | Requires |
|---|---|---|---|
BUILD_TESTING |
Coarse-grained switch; turn off to disable all testing and only build the SDK targets. | On | N/A |
LD_BUILD_UNIT_TESTS |
Whether C++ unit tests are built. | On | BUILD_TESTING; NOT LD_BUILD_SHARED_LIBS |
LD_TESTING_SANITIZERS |
Whether sanitizers should be enabled. | On | LD_BUILD_UNIT_TESTS |
LD_BUILD_CONTRACT_TESTS |
Whether the contract test service (used in CI) is built. | Off | BUILD_TESTING |
LD_BUILD_EXAMPLES |
Whether example apps (hello world) are built. | On | N/A |
LD_BUILD_SHARED_LIBS |
Whether the SDKs are built as static or shared libraries. | Off (static lib) | N/A |
LD_DYNAMIC_LINK_BOOST |
If building SDK as shared lib, whether to dynamically link Boost or not. Ensure that the shared boost libraries are present on the target system. | On (link boost dynamically when producing shared libs) | LD_BUILD_SHARED_LIBS |
LD_DYNAMIC_LINK_OPENSSL |
Whether OpenSSL is dynamically linked or not. | Off (static link) | N/A |
LD_BUILD_REDIS_SUPPORT |
Whether the server-side Redis Source is built or not. | Off | N/A |
Note: if building the SDKs as shared libraries, then unit tests won't be able to link correctly since the SDK's C++ symbols aren't exposed. To run unit tests, build a static library.
[!WARNING]
When building shared libraries C++ symbols are not exported, only the C API will be exported. This is because C++ does not have a stable ABI.
Basic usage example:
mkdir -p build && cd build
cmake -G"Unix Makefiles" ..Slightly more advanced example - build shared libraries, and don't build any of the testing components:
mkdir -p build && cd build
cmake -G"Unix Makefiles" -DLD_BUILD_SHARED_LIBS=On -DBUILD_TESTING=Off ..The example uses make, but you might instead use Ninja,
MSVC, etc.
LaunchDarkly overview
LaunchDarkly is a feature management platform that serves trillions of feature flags daily to help teams build better software, faster. Get started using LaunchDarkly today!
Testing
We run integration tests for all our SDKs using a centralized test harness. This approach gives us the ability to test for consistency across SDKs. These tests cover each method in the SDK, and verify that event sending, flag evaluation, stream reconnection, and other aspects of the SDK all behave correctly.
Contributing
We encourage pull requests and other contributions from the community. Check out our contributing guidelines for instructions on how to contribute to this SDK.
About LaunchDarkly
- LaunchDarkly is a continuous delivery platform that provides feature flags as a service and allows developers to
iterate quickly and safely. We allow you to easily flag your features and manage them from the LaunchDarkly dashboard.
With LaunchDarkly, you can:
- Roll out a new feature to a subset of your users (like a group of users who opt-in to a beta tester group), gathering feedback and bug reports from real-world use cases.
- Gradually roll out a feature to an increasing percentage of users, and track the effect that the feature has on key metrics (for instance, how likely is a user to complete a purchase if they have feature A versus feature B?).
- Turn off a feature that you realize is causing performance problems in production, without needing to re-deploy, or even restart the application with a changed configuration file.
- Grant access to certain features based on user attributes, like payment plan (eg: users on the ‘gold’ plan get access to more features than users in the ‘silver’ plan). Disable parts of your application to facilitate maintenance, without taking everything offline.
- LaunchDarkly provides feature flag SDKs for a wide variety of languages and technologies. Read our documentation for a complete list.
- Explore LaunchDarkly
- launchdarkly.com for more information
- docs.launchdarkly.com for our documentation and SDK reference guides
- apidocs.launchdarkly.com for our API documentation
- blog.launchdarkly.com for the latest product updates