Look for gperf, and use it to generate the hash-based lookup for the
entities; this replaces the static generated file in the sources,
adding a build time only dependency on gperf.
This uses the newly added FindGperf.cmake in ECM, see [1].
Details
Details
- Reviewers
- None
- Group Reviewers
Frameworks - Commits
- R270:883e1ada57c4: Generate gperf output at build time
Builds fine as before, and the gperf output in the build directory
matches the removed generated source.
Diff Detail
Diff Detail
- Repository
- R270 KCodecs
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
Did you intend to make GPerf a hard dependency of KCodecs?
https://build-sandbox.kde.org/job/Frameworks%20kcodecs%20kf5-qt5%20FreeBSDQt5.7/6/console
Comment Actions
Yes, that's the whole point of D3830 and this one...
Also, now even khtml has gperf has required build dependency.
Comment Actions
Please remember that adding *any* build dependency *requires* notification to Sysadmin, which was not done in this case. Please see https://community.kde.org/Policies/Dependency_Changes_and_CI
This broke the FreeBSD and Windows builds of both of those on the new CI.
I've now made GPerf available on both of those, however please do ensure we are notified in *advance* of patches landing which add dependencies so we can make them available in advance and not have to react to breakages.
Comment Actions
The Ci mentioned in this page was already covered.
This broke the FreeBSD and Windows builds of both of those on the new CI.
What is the new CI? Where is it mentioned in the page above?
While I can understand your point of view, surely I cannot think about systems which are not even mentioned in the official documentation linked to me.
Comment Actions
It's located at https://build-sandbox.kde.org/
We're currently in a transitional period between the two systems - the new one has already been announced on various mailing lists including kde-core-devel.