Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: preliminary find_package support #452

Merged
merged 6 commits into from
Oct 8, 2024

Conversation

cwaldren-ld
Copy link
Contributor

@cwaldren-ld cwaldren-ld commented Oct 7, 2024

This PR adds preliminary support for:

find_package(launchdarkly REQUIRED)

target_link_libraries(app 
        PRIVATE 
        launchdarkly::{launchdarkly-cpp-server,launchdarkly-cpp-client}
)

It treats the C++ monorepo as the installable unit. In the very near future, this will likely be refactored so that we have two packages. If you want both on the same host, you'd need to install both (and there'd be some redundancy.)

Currently there is only one version, 0.1.0. This isn't updated by release-please.

For these two reasons, I'm indicating that this is preliminary and subject to change form.

@cwaldren-ld cwaldren-ld force-pushed the cw/SDK-354-cmake-find-package branch from 6818481 to a9bfe15 Compare October 7, 2024 21:53
@@ -6,7 +6,7 @@ cmake_minimum_required(VERSION 3.19)
include(CMakeDependentOption)

project(
LaunchDarklyCPPSDKs
Copy link
Contributor Author

@cwaldren-ld cwaldren-ld Oct 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Attempting to unify the project name with the target alias namespace (e.g. launchdarkly::server).

This is what users will encounter when they call find_package, so it would be predictable to have that be the same as what they link against.

@@ -6,7 +6,7 @@ cmake_minimum_required(VERSION 3.19)
include(CMakeDependentOption)

project(
LaunchDarklyCPPSDKs
launchdarkly
VERSION 0.1
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: currently the version number isn't being updated, and I don't have a great plan for how that will work. Likely I will change to exporting two different package configs rather than the monorepo itself.

@cwaldren-ld cwaldren-ld force-pushed the cw/SDK-354-cmake-find-package branch from da6370e to 410e69c Compare October 7, 2024 23:14
@cwaldren-ld cwaldren-ld force-pushed the cw/SDK-354-cmake-find-package branch from 410e69c to c51b5c2 Compare October 7, 2024 23:16
@cwaldren-ld cwaldren-ld marked this pull request as ready for review October 7, 2024 23:50
@cwaldren-ld cwaldren-ld requested a review from a team as a code owner October 7, 2024 23:50
@@ -36,6 +35,15 @@ runs:
# along in the same manner to those test projects via the command line.
BOOST_ROOT: ${{ steps.install-boost.outputs.BOOST_ROOT }}
OPENSSL_ROOT_DIR: ${{ steps.install-openssl.outputs.OPENSSL_ROOT_DIR }}
CMAKE_INSTALL_PREFIX: ../LAUNCHDARKLY_INSTALL
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm arbitrarily installing into this folder here. Later, this folder is injected into the cmake configure step so find_package looks there for launchdarklyConfig.cmake.

That's one use-case, but it would also be good to check:

  1. If you don't give it an install prefix, and just run cmake --install .
  2. Then if you invoke find_package without specifying a custom CMAKE_PREFIX_PATH
  3. It will work, due to find_package's lookup logic magic.

find_package(Boost 1.81 REQUIRED COMPONENTS json url coroutine)
message(STATUS "LaunchDarkly: using Boost v${Boost_VERSION}")

include(${CMAKE_FILES}/certify.cmake)
set(FOXY_BUILD_TESTING OFF)
add_subdirectory(vendor/foxy)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a new FOXY_BUILD_TESTING to avoid the whole "get the previous value of BUILD_TESTING, set it to off, add_subdir, set the value back.." song and dance.


```bash
mkdir -p build && cd build
cmake -G"Unix Makefiles" ..
# Use 'make' as the build system.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might as well advocate for "modern" cmake commands (-B build -S .)

@@ -13,4 +13,8 @@ FetchContent_Declare(googletest
)
# For Windows: Prevent overriding the parent project's compiler/linker settings
set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)

# Disable installation of googletest
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could guard this with some kind of config option, that maybe is tied into LD_BUILD_UNIT_TESTS or something. For now, don't attempt to install googletest when the SDK is installed.

@@ -0,0 +1,16 @@
include(CMakeFindDependencyMacro)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not entirely sure how to support this properly. With find_package, the idea is that the SDK was already built. Now, you may want to decide whether to statically or dynamically link boost/openSSL.

But that depends on how you built the SDK in the first place.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, they basically just need to match.

Unless we start building a bunch of permutations. I don't think that sounds amazing though. (Boost basically does this and it never seems to work when I actually use it.)

@@ -37,7 +37,6 @@ target_sources(${LIBNAME} PRIVATE
flag_manager/context_index.cpp
flag_manager/flag_manager.cpp
flag_manager/flag_persistence.cpp
bindings/c/sdk.cpp
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was just a redundant entry.

@@ -46,22 +45,29 @@ target_link_libraries(${LIBNAME}
PRIVATE Boost::headers Boost::json Boost::url launchdarkly::sse launchdarkly::internal foxy)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes in most of these sub-lib CMakeLists.txt are:

  1. Switch from target_include_directories(${LIBNAME} PUBLIC ../include to one that uses generator expressions, so it works at build and installation time
  2. Swap out raw lib or bin paths with GNUInstallDir variables
  3. Install the targets to our LD_TARGETS_EXPORT_NAME


find_package(launchdarkly REQUIRED)

add_executable(use_find_package_server main_server.cpp)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You may wonder "why launchdarkly::launchdarkly-cpp-server"? Because when I originally named the targets, I was thinking "global namespace, it might clash with someone's server or client target."

Not sure how to make this match our launchdarkly::{client,server} aliases that are usable in the add_subdirectory case.

@@ -1,23 +0,0 @@
cmake_minimum_required(VERSION 3.11)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved into foxy, since this is really a foxy dependency.

@cwaldren-ld cwaldren-ld requested a review from kinyoklion October 8, 2024 16:23
@cwaldren-ld cwaldren-ld merged commit 1ca48d5 into main Oct 8, 2024
23 checks passed
@cwaldren-ld cwaldren-ld deleted the cw/SDK-354-cmake-find-package branch October 8, 2024 23:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants