fix: CMake package and imported library target names

[ta7mid]

This PR addresses the following issues encountered/noted when creating a Homebrew formula for reflect-cpp:

• libbson ≥2.0.0 renamed its CMake config package (bson-1.0 → bson) and imported targets (mongo::bson_* → bson::*). CMakeLists.txt was switched to the new names in Fix the Github Actions runners #695, but the installed reflectcpp-config.cmake still looks for bson-1.0. Both files now accept either naming, so libbson 1.x keeps working too.
• When REFLECTCPP_USE_VCPKG is false, reflect-cpp links with arrow::arrow, but no such target is provided by the CMake config packages installed with Apache Arrow ≥21.0.0, regardless of whether vcpkg is used. Arrow/Parquet are now linked via Arrow::arrow_{static,shared} and Parquet::parquet_{static,shared}, which upstream Arrow, vcpkg and Conan's recipe all provide.
• Generator expressions used to specify interface link libraries (as in target_link_libraries(reflectcpp PUBLIC $<IF:$<TARGET_EXISTS:…>…,…>)) are not evaluated and get copied verbatim into the exported reflectcpp-exports.cmake. Targets are now resolved at configure time, so the export lists plain target names.
• When a dependency ships both variants (e.g. Homebrew), reflect-cpp now links the one matching its own type (shared/static), falling back to whichever exists, and fails at configure time if none does. This also fixes FlatBuffers for shared Conan builds (only flatbuffers::flatbuffers_shared exists there) and picks msgpack-c-static for static builds where it exists.

Also:

• libbson is linked PUBLIC again (it was made PRIVATE in Fix the Github Actions runners #695): rfl/bson/*.hpp include <bson/bson.h>, and upstream libbson 2.x installs its headers under include/bson-<version>/, so consumers of an installed reflect-cpp need the include path. vcpkg patches that layout away, which is why CI doesn't notice. Happy to revert this if PRIVATE was intentional.
• conanfile.py: with_csv=True now enables Arrow's CSV module, which the Arrow recipe disables by default.

Tested:

• The full Linux/macOS/Windows CI matrix passes on my fork (linux, macos, windows).
• Conan (shared=True, FlatBuffers + msgpack): builds and exports flatbuffers::flatbuffers_shared, where main fails to configure.
• Static and shared builds against libbson 1.30 + Arrow 21 + msgpack-c 6.1, installed, then a separate project using find_package(reflectcpp) round-trips JSON/BSON/msgpack/CSV.
• Configure-only runs against stub packages that mimic the target names of vcpkg (static and dynamic triplets), Homebrew, Conan and libbson 1.x, checking which targets end up in the exported link interface.

🤖 Generated with Claude Code

[gemini-code-assist]

Summary of Changes

Hello @ta7mid, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refines the CMake build system for reflect-cpp to enhance compatibility with updated versions of external dependencies, specifically libbson (2.0.0+) and Apache Arrow (21.0.0+). It addresses breaking changes in how these libraries expose their CMake packages and targets, ensuring reflect-cpp can correctly find and link against them. The changes also streamline the selection between static and shared library linkage based on the project's build type, improving overall build robustness.

Highlights

• libbson CMake compatibility: Updated CMake configuration to correctly identify and link with libbson versions 2.0.0 and newer, which introduced changes to their package and target names. This includes conditional logic for vcpkg usage and explicit static/shared linkage.
• Apache Arrow CMake targets: Adjusted the linking strategy for Apache Arrow to explicitly use Arrow::arrow_static or Arrow::arrow_shared targets, resolving issues with the arrow::arrow target no longer being provided in newer Arrow versions (>= 21.0.0).
• Shared library linkage preference: Implemented logic to prioritize linking against shared versions of libbson and Apache Arrow when reflect-cpp is configured to build as a shared library, ensuring consistent build behavior.
• vcpkg Arrow configuration: Modified vcpkg.json to disable default features for the arrow dependency, providing more precise control over its build configuration and preventing potential conflicts.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request addresses several issues with dependency handling in CMake for libbson and Apache Arrow. The changes correctly adapt to new package and target names in recent versions of these libraries and simplify the logic for linking static or shared variants. My main concern is with the version range specified for libbson, which is too restrictive and would prevent using versions newer than 2.0.0. I've left specific suggestions to address this in the code.

[liuzicheng1987]

@ta7mid thanks for the PR.

However, it appears that this has broken the Conan build. Could you take another look?

[ta7mid]

@liuzicheng1987 Can you check if it works now?

[liuzicheng1987]

@ta7mid , there still appear to be the same issue with Conan...

[ta7mid]

It's probably fixed now.

[ta7mid]

@liuzicheng1987 Please do another run of the workflow.

[ta7mid]

@liuzicheng1987 I think it's fixed now. Check?

[ta7mid]

I haven't been able to reproduce that error locally.

And it's probably not fixed yet, but this time around I've added some log statements to list all imported targets so I can find the correct Parquet target from the build logs :) And I hope a follow-up commit will have the fix.

Run the check again please?

[liuzicheng1987]

@ta7mid , I am closing this PR due to inactivity and since some of the tests do not pass. If you want to continue your work here, feel free to repoen.

[ta7mid]

Hey, I've just pushed a potential fix :)

[ta7mid]

@liuzicheng1987 Can this be reopened?

[liuzicheng1987]

Sure.

[liuzicheng1987]

@ta7mid I just reopened the PR. Thanks for continuing to work on this

[ta7mid]

Thanks. Can you run the workflows too?

[ta7mid]

@liuzicheng1987 Can you please run the workflows?