Implement utf8cpp dependency check for EBML

[SunBlack]

Added a dependency check for utf8cpp when shared libraries are not built.

Backport from microsoft/vcpkg#53661

[robUx4]

Isn't 73f29d3 sufficient ? Or maybe we should declare the dependency as PUBLIC when it's not fetched ?

Also it seems weird to only do it for static libraries.

We should probably test static/shared and internal/external usage via CMake in the CI.

[SunBlack]

Isn't 73f29d3 sufficient ? Or maybe we should declare the dependency as PUBLIC when it's not fetched ?

No, PRIVATE is correct, as long as utf8cpp is not used in any public header. With PUBLIC, all projects that use ebml would also see the include directories of utf8cpp, even if it isn't necessary.

But it might be enough; you'd have to check whether CMake now omits that from the exported target (or check_required_components doesn't fail).

Also it seems weird to only do it for static libraries.

That's just the difference between the two: with the static approach, everything is linked together at the end, whereas with the dynamic approach, it's done beforehand.

We should probably test static/shared and internal/external usage via CMake in the CI.

That would be the best solution. The same applies to pkg exports. So, basically, there are 4 tasks:

• CMake target with dynamic and static builds
• Pkg test with dynamic and static builds

A test with CPS files would also be nice, but I think there is currently no export for this in this project (requires CMake 4.3)

[robUx4]

I managed to reproduce the issue with #357

There seems to be a EXPORT_PACKAGE_DEPENDENCIES option that might do that, but it's currently experimental. So I guess it needs to be done manually for now...

[robUx4]

It was causing link issues when the utf8cpp library was found in the system.

I used if(@utf8cpp_FOUND@) and it works fine. I don't think we need to differentiate between static and shared builds because in both case the utf8cpp package needs to be there, it won't be linked in the static or dynamic library we build.

[SunBlack]

Feel free to take over with #357 as I just tested it with vcpkg, I don't know the difference to your setup (or don't want spent time on this now)

[SunBlack]

@BillyONeal In case you have an opinion to (@utf8cpp_FOUND@) vs NOT @BUILD_SHARED_LIBS@ feel free.

[robUx4]

Can you confirm this also works with vcpkg?

[BillyONeal]

@BillyONeal In case you have an opinion to (@utf8cpp_FOUND@) vs NOT @BUILD_SHARED_LIBS@ feel free.

I don't have a strong opinion here. It is true that normally what you check in the config should exactly match what is checked in the CMakeLists.txt, but in this case when not utf8cpp_FOUND CMakeLists.txt responds by trying to do FetchContent so there really isn't a direct comparison here. I would argue that it probably should be unconditional rather than guarded by anything since that seems to be what CMakeLists.txt expects.

Can you confirm this also works with vcpkg?

We did merge microsoft/vcpkg#53661 which has this patch; I looked more at "build passed with the patch" and assumed that meant OK rather than following back to the CMakeLists.txt myself. The big thing that is problematic for vcpkg is the FetchContent but we ensure the find_package succeeds so we never see that path.