Add Libqrcodegencpp

[tytan652]

Description

Some Linux distribution (e.g. Ubuntu, Fedora) tweak https://github.com/nayuki/QR-Code-generator to ship it's C and C++ implementations as libraries.

One of the methods is to add files from https://github.com/EasyCoding/qrcodegen-cmake and use CMake to build the libraries which is the method took for this PR.

The C implementation (libqrcodegen) is removed since it is not needed.

I'm aware of #174, so if it get merged first, I will update the pwsh script to add $Targets.

Motivation and Context

Reduce the number of submodules in obs-studio repo and provides those as libraries in obs-deps.
Also this would allow to make obs-websocket submodule-less.

How Has This Been Tested?

CI test build static version, and tested shared on VMs.

tytan652/obs-studio#13 provides binaries:

• Ubuntu 20.04 is failed too because of an API break from Libqrcodegen between 1.5.0 (20.04) and 1.7.0 (22.04) (header file name change), so one more reason to drop Ubuntu 20.04.

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[Conan-Kudo]

I have a patch downstream in Fedora that adapts the websocket plugin to use the system version of qrcodegencpp. Once this is merged, would it be acceptable to get this upstreamed too?

[tytan652]

I have a patch downstream in Fedora that adapts the websocket plugin to use the system version of qrcodegencpp. Once this is merged, would it be acceptable to get this upstreamed too?

Read until the end.

No, because your patch rely on installed cmake modules (made by qrcodegen-cmake) which is:

• non-existent in Ubuntu packages (they don't seem to use the same method as Fedora to make the package) and other small differences
• has a bug with a non-working namespace (qrcodegencpp::qrcodegencpp rather than qrcodegencpp does not work on my testing) fixed upstream

I created a new finder that works for any cases that use qrcodegen.hpp. PatTheMav/cmake-finders#2 which will be added to OBS Studio later.

And here is the branch for my changes for obs-websocket: https://github.com/tytan652/obs-websocket/tree/last_ws_dep_standing

I discovered the existence of libqrcodegencpp package through your patch and thank you for that. But it does not work in all cases, so I had create something that will work almost anywhere.

[Conan-Kudo]

@xvitaly, could you take a look at the bug @tytan652 discovered about your CMake overlay?

[xvitaly]

has a bug with a non-working namespace (qrcodegencpp::qrcodegencpp rather than qrcodegencpp does not work on my testing)

From generated qrcodegen-cpp-targets:

# Create imported target qrcodegencpp::qrcodegencpp
add_library(qrcodegencpp::qrcodegencpp SHARED IMPORTED)

...

# Import target "qrcodegencpp::qrcodegencpp" for configuration "Release"
set_property(TARGET qrcodegencpp::qrcodegencpp APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(qrcodegencpp::qrcodegencpp PROPERTIES
  IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib64/libqrcodegencpp.so.1.8.0"
  IMPORTED_SONAME_RELEASE "libqrcodegencpp.so.1"
  )

Targets will be generated automatically here: https://github.com/EasyCoding/qrcodegen-cmake/blob/master/CMakeLists.txt#L204-L207

[tytan652]

The bug has magically disappeared because of a reboot apparently, CMake why ?.
Sorry @xvitaly for the false alarm.

[tytan652]

Sorry again, @xvitaly I can reproduce it, we are in a transition period in our CMake build-system and I modified the wrong file for Linux. I will write a issue on the qrcodegen-cmake repo rather than continuing the off-topic here.

[xvitaly]

I will write a issue on the qrcodegen-cmake repo rather than continuing the off-topic here.

Great. I'll take a look.

[tytan652]

Commits:

• deps.macos: Add Libqrcodegencpp to macOS deps
• [TO SQUASH] Apply recent macOS deps changes

have been squashed since changes were approved.

[RytoEX]

I almost wish that instead of being in a single script, this were two separate scripts, like:

deps.macos/80-qrcodegencpp.zsh
deps.macos/81-qrcodegencmake.zsh
deps.windows/60-qrcodegencpp.ps1
deps.windows/61-qrcodegencmake.ps1

But I'm not sure that would necessarily be any "better" than what is already here, and it might be more convoluted to get that working, so this is fine as-is if @PatTheMav is already fine with it.

[tytan652]

I almost wish that instead of being in a single script

qrcodegen-cmake is a big "patch" meant to enable the Qr-Code-Generator C and C++ implementation to build as standalone libraries with CMake.

They can't be separated since we can't build Qr-Code-Generator C and C++ implementation as libraries without qrcodegen-cmake.

[PatTheMav]

That's actually an oversight on my end - the CMake files need to be added via a patch file, not via a second checkout (and using relative path patterns like mkcd ../something is also no bueno, instead pushd/popd pairs should be used, but when using a proper patch file to generate the required CMake files directly in the source dir this should be unnecessary anyway).

[tytan652]

I will try to avoid the "relative path", but I will not increase the maintenance cost by generating a patch from a git repo meant to be copied inside another repo.

[PatTheMav]

I will try to avoid the "relative path", but I will not increase the maintenance cost by generating a patch from a git repo meant to be copied inside another repo.

That's the canonical way we add CMake support to projects that don't have it. The other option would be a fork that has that patch applied. It seems very roundabout to me to have one repository with the sources, and another repository with the build system files, especially as you cannot combine both into the same directory.

[RytoEX]

I will try to avoid the "relative path", but I will not increase the maintenance cost by generating a patch from a git repo meant to be copied inside another repo.

That's the canonical way we add CMake support to projects that don't have it. The other option would be a fork that has that patch applied. It seems very roundabout to me to have one repository with the sources, and another repository with the build system files, especially as you cannot combine both into the same directory.

Unfortunately, the CMake repo itself recommends this method:

git clone https://github.com/nayuki/QR-Code-generator.git qrcodegen
git clone https://github.com/EasyCoding/qrcodegen-cmake.git qrcodegen-cmake
ln -s ../qrcodegen-cmake/{cmake,CMakeLists.txt} qrcodegen/
mkdir -p qrcodegen-build
cmake -S qrcodegen -B qrcodegen-build -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_EXAMPLES:BOOL=ON -DBUILD_TESTS:BOOL=ON
cmake --build qrcodegen-build

So as far as that project is concerned, git cloning both projects is correct. Though, they suggest side-by-side checkouts and not one within the other. The suggested symlink step achieves the same end result as putting both projects into the same directory, but keeps separate git checkout directories.

[PatTheMav]

I will try to avoid the "relative path", but I will not increase the maintenance cost by generating a patch from a git repo meant to be copied inside another repo.

That's the canonical way we add CMake support to projects that don't have it. The other option would be a fork that has that patch applied. It seems very roundabout to me to have one repository with the sources, and another repository with the build system files, especially as you cannot combine both into the same directory.

Unfortunately, the CMake repo itself recommends this method:

git clone https://github.com/nayuki/QR-Code-generator.git qrcodegen
git clone https://github.com/EasyCoding/qrcodegen-cmake.git qrcodegen-cmake
ln -s ../qrcodegen-cmake/{cmake,CMakeLists.txt} qrcodegen/
mkdir -p qrcodegen-build
cmake -S qrcodegen -B qrcodegen-build -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_EXAMPLES:BOOL=ON -DBUILD_TESTS:BOOL=ON
cmake --build qrcodegen-build

So as far as that project is concerned, git cloning both projects is correct.

Yeah "one within the other" is not possible (except for downloading the tarball from GitHub and extracting it in place). I don't like it, but the implementation in the PR is fine.

[RytoEX]

Yeah "one within the other" is not possible (except for downloading the tarball from GitHub and extracting it in place). I don't like it, but the implementation in the PR is fine.

Right. I think we can explore an alternative implementation in the future, or encourage the base project to add proper CMake support.

[xvitaly]

The other option would be a fork that has that patch applied. It seems very roundabout to me to have one repository with the sources, and another repository with the build system files, especially as you cannot combine both into the same directory.

The QR-Code-generator upstream is too unfriendly to external contributors. They don't accept pull requests.

I think we can explore an alternative implementation in the future

This is a good idea. LibreOffice has already done this and moved to another QR code library.

or encourage the base project to add proper CMake support.

Our PR with full CMake support: nayuki/QR-Code-generator#140

That's why we created our own repo.

[RytoEX]

Whitespace nit.

[RytoEX]

Seems fine. Just need to determine merge order with respect to other pending PRs.