FYI I'm using a strict 100 chars limit nowadays on all my KWinFT projects (with the exception of KWinFT itself for now) and I'm very happy with this decision.

I agree. A limit of 100 is arbitrary and harmful. Unfortunately clang-format doesn't seem to have a way to make lines over a certain length less desirably, but still allowed if the break would be ugly, so it is better to just allow long lines.

For my 2 wanted changes, I created a new merge request
https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/20

As said above, I think 100 is a bad idea. Can we close this?

Ade makes an interesting point, if Kitware wants to add the 3rd clause then they can just add it to the BSD-2-clause code which has been sent upstream. But adding in 3rd clause BSD in places could limit where it gets used. And if we use the wrong name for the author then it's incompatible anyway and blocks use.

• If we allow BSD-3-Clause, it should be a separate explicit entry in the alternative-licenses list.
• The official SPDX text has "3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission." where the italics indicate that variants exist; the sample text is pretty generic IMO.
• CMake upstream specifically instructs "We do not require any formal copyright assignment or contributor license agreement. Any contributions intentionally sent upstream are presumed to be offered under terms of the OSI-approved BSD 3-clause License. See Copyright.txt for details." (here)

I'm not a fan of BSD 3 clause because it often includes the name of the copyright holder, and that can get complex when new copyright holders come along or if you don't care much and just want to copy and paste.

In D21695#675056, @elvisangelaccio wrote:

New attempt at https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/6

New attempt at https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/6

Moved to invent.

A unit test would be good to have. The test for ECMGeneratePkgConfigFile might be a sample for this.

• Clarify docs

• Rename variable

+1 overall, good idea.

This is used in https://invent.kde.org/sysadmin/ci-tooling/-/merge_requests/68

So many things to take care of :-)

tested successfully with the openSUSE package which uses absolute paths

This will make our configure steps readable again. Thanks!

Ah, right. If you are using a normal sysroot for system libs, but conan for some libs then it makes sense!

I'm using conan, not doing cross compilation.

Though... How does it come that you do not have SYSROOT set in your case? Won't that break in other cases?

The Build worked. So this solves the issue for me!

Thanks for the quick test!

looks good! yours is probably a bit more "CMakeish"! So feel free to continue with that one and close this.

Fix error: regex "[^/]*" matched an empty string.

My reason is basically the same. Will try this version too.

Hi @dfaure. It looks pretty much the same and I think it should work for us. I will kick off a build to confirm.

Could you test if my patch in D29274 solves your problem? By making these lines relative to the location of the .pri file, it should work very well in a sysroot context as well.

D29096 also wants to touch those entries, for different reasons. You may want to align here.

Any chance for a simple unit test to check the generation does what is expected (or catches bad input)? :)

A bit unsure if the arg name "TEMPLATES" is good, or if perhaps should be renamed to "INPUT". Just mentioning, not preferring one over the other. So far have not found existing samples to take as lead for consistent argument naming.

Not having done much cross-compilation-library-setups naively I would have thought that when building a library which uses ECMGeneratePriFile and preparing it for cross-compilation, the installation prefix would be hardcoded into the generated artifacts.. Seems that instead files are relocated sometimes, changing their path & prefix, or tools snipping of some things?

Thanks for the explanation, fear though I am missing some details and thus have not yet understood the problem and the solution. Not having done much cross-compilation-library-setups naively I would have thought that when building a library which uses ECMGeneratePriFile and preparing it for cross-compilation, the installation prefix would be hardcoded into the generated artifacts.. Seems that instead files are relocated sometimes, changing their path & prefix, or tools snipping of some things? So $$[QT_SYSROOT] would make up for that, when having a library build normally for a system, but then deployed to the cross-compilation system below some path? Just curious in case you have time to teach me, positioning myself here as curious person at the sideline :)

+1 makes sense

The SYSROOT variable should not (directly) impact that. The install directory is configured by ECM_MKSPECS_INSTALL_DIR, which usually will point to /usr/lib/mkspecs/modules/ on Linux. For a cross-compile toolchain it will however be additionally prefixed with separate path. But Qt and qmake will also be configured with that prefix so those know to lookup the mkspecs dir under that prefix. Issuing QT += <module> can then trigger the including of the include and lib paths from the .pri generated by this code. So the case I am trying to fix with this patch is the case where the .pri is found (so ECM_MKSPECS_INSTALL_DIR was specified correctly) but now the libs and include paths are pointing to /usr/{include,lib} and not to <cross-compile-prefix>/usr/{include,lib}. Now since <cross-compile-prefix> can differ depending on the installation dir of the tool chain it may not be possible to know that path during compile / install time. However, we can assume that Qt / qmake will know about the sysroot (which is the prefix essentially). So as long qmake is configured for the cross compile our Qt module now should be too.

No current clue about qmake, just wondering from my little knowledge:
how does having $$[QT_SYSROOT] here influence any QMAKEPATH env var set? Would pri files installed into a custom prefix still be found?

Warning: I have not really investigated in full detail if the current code of FindKF5 is completely sane besides a quick check, more or less assume that it has worked all the time, so the new warning here can be silenced.

+1, I can't judge the impact on the subsequent pipeline though, such as the fdroid repo handling.

Add docs rst

• Improve docs
• Add DESTINATION arg

Some first quick comments, not yet looked at code itself.

Are we stuck somewhere? The patch looks good to me.

Add STATIC_LIBNAME and DYNAMIC_LIBNAME options

I don't have enough CMake knowledge to give code comments, but here are some things I can notice in case they help in review:

1. The function specifically mentions Cargo workspace, which is basically a Rust alternative to TEMPLATE = subdirs in qmake. It doesn't seem though that the current implementation has code specific for this project type, and it can probably work just as well for normal executable and library projects. Am I missing something? If it can't, how would developers use this ECM module if they don't need the workspace? Can it be generalized?
2. In the implementation that I mentioned, the resulting target gets a name that we can use directly, whereas in your usage example you have to manually use an artifact variable to actually be able to link. You also manually specify the shared library extension; will this require a platform-dependent wrapper in end user's CMakeLists to be able to use this on e.g. Windows?

Thank you for your work :)

Address feedback

Will /tmp then still work on Windows?

extra escape

update

In D28444#639020, @cblack wrote:

CMake needs to know what files Cargo wants to build in order to invoke it only when Rust files change. There's no reason to invoke Cargo every time make is ran when CMake has the ability to keep track of dirty files.

In D28444#638988, @IlyaBizyaev wrote:

In D28444#638877, @cblack wrote:

CMake needs to know when the Rust source has changed so it can rebuild it

Changes to Rust code need to be tracked by Cargo, not by CMake

In D28444#638877, @cblack wrote:

CMake needs to know when the Rust source has changed so it can rebuild it

In D28444#638540, @IlyaBizyaev wrote:

In D28444#638430, @cblack wrote:

more than half of Ikona's CMakeLists.txt is boilerplate dedicated to integrating Rust with the rest of the project

I don't understand why your function needs a list of Rust files, even though those are already handled by Cargo. Looks boilerplate-ish...

In D28444#638430, @cblack wrote:

more than half of Ikona's CMakeLists.txt is boilerplate dedicated to integrating Rust with the rest of the project

In D28444#638435, @apol wrote:

Will this make all the boilerplate in ikona disappear?

I feel like one of the reasons KDE doesn't use Rust more is that using it in the build system side is pain. Case in point: more than half of Ikona's CMakeLists.txt is boilerplate dedicated to integrating Rust with the rest of the project. I'd like to get this in ECM to lower the barrier for other KDE applications and libraries to utilize Rust.

In D28444#638428, @apol wrote:

I wonder if this is covering a very widespread use-case. If there's just one application that needs it, it could make sense to keep it there and once it's polished, we put it in ECM to share.

Code per se looks okay, not that I've ever used a rust workspace.

I'm not good at CMake modules, but maybe this code (which I used in a project) is useful:
https://github.com/Devolutions/CMakeRust