On samedi 4 février 2017 10:46:41 CET Stephen Kelly wrote: > On 02/04/2017 08:14 AM, Matthew Dawson wrote: > > On Thursday, February 2, 2017 10:08:53 PM EST Jaroslaw Staniek wrote: > >> On 1 February 2017 at 14:34, David Faure <fa...@kde.org> wrote: > >>> One note though: this is a failure to link a unittest, your release > >>> isn't > >>> blocked, you can just disable the building of unittests in kconfig. > >>> > >>> The double definition can be explained, the unittest links to > >>> KF5ConfigCore > >>> and then also compiles in ../src/core/kconfigdata.cpp because that class > >>> is not > >>> exported. > >> > >> Hi, > >> Apparently it is since eab822e20620 (Jan 15). > >> The bug #375654 does not seem to provide version info but the fix isn't > >> just released, right? CC'd Stephen Kelly. > > > > It seems this class was exported so it can be accessed through the Python > > bindings. Considering it wasn't exported before, I'm wondering why it was > > exported for Python? > > > > Since removing it would be an ABI for Python scripts and the tagging is > > happening today, can we just back out the KEntryMap API from Python? We > > can add it back for the next release if there is a use case for it. > > > > @David Faure, when do you plan on tagging this change? For now I > > committed a change to the auto test so it will at least build on Windows > > (b939b48f8d5e5eaf9a51a7e9bda2ad8cedca27d9) which should be included. > > Would > > there be time to remove KEntryMap before the tag/release? > > In case you want to not export the class instead, the attached should work.
Ah, I see what the problem is: KConfigBackend is exported + installed, and uses KEntryMap in its API, that's why you exported it. These are the remnants of a time when it was supposed to be possible to implement kconfig backends externally. But nobody uses KConfigBackend, it's exported for nothing https://lxr.kde.org/ident?_i=KConfigBackend&_remember=1 -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
