New Base for symbols in Qt5.6

[Dmitry Shachnev]

On Sun, Dec 27, 2015 at 03:41:39PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
>>> Dmitry: we still need to look for private symbols as we used to, IIRC
>>> there
>>> where some cases of upstream not marking private symbols as such. having
>>> both methods at hand will surely catch those cases.
>> 
>> However I also know that our current algorithm has some false positives —
>> i.e. it marks functions using *pointers* to private objects as private, even
>> if they are part of public API. I thought that by fully switching to
>> upstream algorithms, we will get rid of that bug.
>
> Do you have an example of such a case? The script was being run over private
> headers only, so even pointers to private functions should be private.

There was a case where the inline constructor for a public Qt class called
internally another (private) constructor which accepted a pointer to a private
Qt class as an argument.

Thus a package using that inline constructor ended up with wrong dependency on
qtbase-abi-x-y-z, even though it used only public API.

Unfortunately I couldn't find that in irclogs, but we have definitely discussed
that.

>> Do you have any examples of "upstream not marking private symbols as such"?
>
> Forget that, I mixed stuff. The symbols are marked as private by using a list
> created by syncqt.pl, so things should be fine.

OK, so just using my script is probably fine.

>> In any case I think we should keep the logic in pkg-kde-tools package, i.e.
>> replace the existing script with mine or extend its logic. I hope Python
>> dependency is not a problem, is it?
>
> I'm totally for it. If it becomes a problem for someone we can consider
> generating a new binary package from the same source and adding the python
> dependency there. We might even do that from the beginning.

Maybe we should actually rewrite it in Perl or shell. (Any volunteers? :))

> OK, I've checked the branch and I merged it to experimental. Please do not
> forget to add the proper copyright headers to the scripts.

Ack.

> Should we keep the merging script? I think having it on git's story should be
> enough. I also don't mind shipping it once in the packages.

This script should be used only once for all Qt 5.6 modules. So maybe let's
keep it in Git until we migrate all the modules, but not ship in any binary.

--
Dmitry Shachnev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20151228/4ca7b873/attachment-0001.sig>