Mon, Jun 29
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.
Sun, Jun 28
Sun, Jun 21
Thu, Jun 11
Mon, Jun 8
Moved to invent.
May 29 2020
A unit test would be good to have. The test for ECMGeneratePkgConfigFile might be a sample for this.
May 22 2020
- Clarify docs
May 13 2020
May 11 2020
- Rename variable
+1 overall, good idea.
This is used in https://invent.kde.org/sysadmin/ci-tooling/-/merge_requests/68
May 9 2020
So many things to take care of :-)
May 8 2020
tested successfully with the openSUSE package which uses absolute paths
May 4 2020
This will make our configure steps readable again. Thanks!
Apr 30 2020
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!
Apr 29 2020
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.
Apr 28 2020
Apr 23 2020
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?