+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

Quick review while I had some spare minutes, to keep things going.

All of the things!

I agree with almost all those suggestions. Though it's a lot more complex, so I might need some help with some of that.

A .rst file in the docs/module/ directory is needed, otherwise the documentation generation will not pick up this, as it runs only over docs/.
Please enable the documentation generation in your ecm build and check for yourself, by e.g. ensuring BUILD_HTML_DOCS is ON and browsing the generated html in the build dir.

Nice one! I cannot test right now though, I might do it over the weekend (do not hold on me though).

Good idea. Done

Can you please adapt it so _template can be an absolute path?

Thanks!

In D26749#620142, @apol wrote:

Seems ready to land to me.

Seems ready to land to me.