fix: cmake installation for yocto build

[frogarian]

INSTALL_PLUGINSDIR is set by qt6-cmake.bbclass in meta-qt6

[gemini-code-assist]

Summary of Changes

Hello @frogarian, 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 addresses an issue with CMake-based plugin installation, particularly within Yocto build environments. It introduces a configurable variable for the plugin installation directory, enabling external build systems to dictate the correct path. This change ensures that plugins are installed to the appropriate location when building with Yocto, while also providing robust default behavior for other build configurations.

Highlights

• Yocto Build Compatibility: Introduced INSTALL_PLUGINSDIR as a CMake cache variable, allowing external build systems like Yocto to define the plugin installation path, thus resolving installation issues in Yocto environments.
• Flexible Plugin Installation: The script now checks if INSTALL_PLUGINSDIR is already set; if not, it falls back to sensible default paths, ensuring broader compatibility for various build scenarios.
• Refined Default Paths: Updated the default plugin installation paths to use ${CMAKE_INSTALL_LIBDIR}/plugins or ${CMAKE_INSTALL_BINDIR} as a base, with platforminputcontexts appended in the final install step.

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 effectively addresses the CMake installation process, particularly for Yocto builds, by introducing a flexible "INSTALL_PLUGINSDIR" cache variable. This allows external build systems to easily override the plugin installation path. The use of standard CMake variables like "CMAKE_INSTALL_LIBDIR" and "CMAKE_INSTALL_BINDIR" for default paths significantly improves the maintainability and portability of the build system. Additionally, centralizing the "platforminputcontexts" suffix in the "install" command enhances consistency.

[EddyTheCo]

I like the fact QT_DIR variable is no longer used.
But this should not be changed because the thing fix: cmake installation for yocto build should be solved by using if (NOT INSTALL_PLUGINSDIR).
So this is an additional change to a thing that was working correctly before and was the desire of the developer.
I would recommend you create an issue(or in the PR conversation) explaining what you are trying to solve with this pr.

[frogarian]

Oh. It seems that something got mixed up. Actually I wanted to keep everything as is, except that if INSTALL_PLUGINSDIR is set, it should be used. Updated my code.

[EddyTheCo]

Many thanks for your quick response. I was testing the CMake installation, and it does not work for me, even using the main branch.
In my opinion, this project should not depend on a Yocto recipe passed variable(as it should not depend on QT_DIR).
I think the general installation using CMake has to be fixed.

[EddyTheCo]

It is not clear to me what problem this PR is intended to solve.
This PR changes the installation location of the library: previously, the library was installed in the Qt installation path when it was the root CMake project, but with this change, it will no longer be.
This may affect how Qt is able to find this library and qml module.
By testing the project, the CMake installation is not working before and after this PR.
A proper issue and a more complete PR should be created.

[EddyTheCo]

Now the PR uses only this INSTALL_PLUGINSDIR variable that can be set by passing -D to cmake and reduces duplicated text.
So I do not see why not to accept this PR.