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.