Bug#651696: Please use a different variable name than slots in keymaker.h
tags 651696 + pending fixed-upstream thanks On Sun, Dec 11, 2011 at 02:39:20PM +0100, Kai Wasserbäch wrote: Olly Betts schrieb am 11.12.2011 14:31: On Sun, Dec 11, 2011 at 01:48:57PM +0100, Kai Wasserbäch wrote: I've been busy packaging (or rather making fit for release) QApt, which uses Xapian. Currently QApt and some other programs also using Qt (e.g. packagesearch [0]) need to employ a workaround [1] to be able to use both Qt and Xapian in conjunction. This is because both Qt and Xapian have slots. Hmm, slots is a class member in Xapian. Is Qt really defining slots as a pre-processor macro? Haven't they heard of not polluting the global namespace? I think they have, by now. I can only guess here, but as the slots stuff is one of the older but still core parts of Qt, I suspect they didn't care _too_ much back then. One can use Q_SLOTS today. But slots will still be there in the headers. You can disable Qt's macro definitions for slots, etc with no_keywords: http://qt-project.org/doc/qt-4.7/signalsandslots.html#id-5f48cb91-f39a-4dda-a168-4fe9bdd07e49 I think promoting use of no_keywords and Q_SLOTS is the best solution. It's not sensible for Qt to own a generic token like slots and force the rest of the world to stop using it. Even acting as if they own Q_* seems unhelpful - there are only 26 single letter prefixes. I've added a check to the Xapian header upstream for 1.2.11 which gives a clear error if slots and Q_OBJECT are defined, suggesting including xapian.h first or using no_keywords. Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651696: Please use a different variable name than slots in keymaker.h
Package: xapian-core Version: 1.2.7-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear xapian maintainers, I've been busy packaging (or rather making fit for release) QApt, which uses Xapian. Currently QApt and some other programs also using Qt (e.g. packagesearch [0]) need to employ a workaround [1] to be able to use both Qt and Xapian in conjunction. This is because both Qt and Xapian have slots. Hence I'd like to ask you to consider changing slots in keymaker.h (and of course the other files including keymaker.h) to something different. I know this would require some more work from the packages using Xapian, but the amount seems way smaller than changing all Qt packages. Thank you in advance! Kind regards, Kai Wasserbäch [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639076 [1] http://anonscm.debian.org/gitweb/?p=pkg-kde/kde-extras/qapt.git;a=commitdiff;h=bdaabec2ee2e0ca19299814e08e3102c2b830a81 - -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.1.5-esgaroth (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQGcBAEBAgAGBQJO5KatAAoJEKMJ12zh3lnSm2AMAMGuvYMqkRxJ0fZZCdZlFlUd bmmE7Gzb/mRJHvwmTVIQWCn3/mkf+zrZc7Nj6rHxtfd1KdS3GssV4bSZStBnqiHq 4YO55RA0gyeQtSulbqAhyCN2t73K/35K1bN9GrCHXMw9fyikMd+anaLammA3qF3N +3s9ewax8+wzAyt8MgbAvUA8yMWqXqRHU02AKcExEHizGZsN4F2ovYwVfnimhibs bGJBTcz73+RF3eHzFKybumA+1MPcURpFWXEMGmZFSyhgxvRSRwqIwmfTjEK0qaOr r95Ul/zX/0uMnroo+aiKaQuvG6dv+g0INV13nDECv6HmDk7HkrKjkLvkteLQoW+G iFnbc868MEFJjLkPG+hEd81jA33QTryQ7SRWCYE1o29V9rVIsmGIO3qHa5SixXYC 6ix0I5cfAJQyNkkuq2f63y9j/mU3jp3gw22wuSkzlPmUDWA2VnkfKhJiP9AuVruM L4z3N/wdY8vgh854z1/fjtAxj9ETEVpB8TE5yjM//Q== =eEnX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651696: Please use a different variable name than slots in keymaker.h
On Sun, Dec 11, 2011 at 01:48:57PM +0100, Kai Wasserbäch wrote: I've been busy packaging (or rather making fit for release) QApt, which uses Xapian. Currently QApt and some other programs also using Qt (e.g. packagesearch [0]) need to employ a workaround [1] to be able to use both Qt and Xapian in conjunction. This is because both Qt and Xapian have slots. Hmm, slots is a class member in Xapian. Is Qt really defining slots as a pre-processor macro? Haven't they heard of not polluting the global namespace? And if so, why not just include xapian.h *first*? Hence I'd like to ask you to consider changing slots in keymaker.h (and of course the other files including keymaker.h) to something different. I know this would require some more work from the packages using Xapian, but the amount seems way smaller than changing all Qt packages. I think that would mean an incompatible ABI change - if so, it certainly can't happen in the 1.2.x series. Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651696: Please use a different variable name than slots in keymaker.h
Dear Olly, Olly Betts schrieb am 11.12.2011 14:31: On Sun, Dec 11, 2011 at 01:48:57PM +0100, Kai Wasserbäch wrote: I've been busy packaging (or rather making fit for release) QApt, which uses Xapian. Currently QApt and some other programs also using Qt (e.g. packagesearch [0]) need to employ a workaround [1] to be able to use both Qt and Xapian in conjunction. This is because both Qt and Xapian have slots. Hmm, slots is a class member in Xapian. Is Qt really defining slots as a pre-processor macro? Haven't they heard of not polluting the global namespace? I think they have, by now. I can only guess here, but as the slots stuff is one of the older but still core parts of Qt, I suspect they didn't care _too_ much back then. One can use Q_SLOTS today. But slots will still be there in the headers. And if so, why not just include xapian.h *first*? I could do that too and can propose the required changes to QApt's upstream, but I'd prefer, if both Xapian and Qt could be used alongside each other without such requirements. Hence I'd like to ask you to consider changing slots in keymaker.h (and of course the other files including keymaker.h) to something different. I know this would require some more work from the packages using Xapian, but the amount seems way smaller than changing all Qt packages. I think that would mean an incompatible ABI change - if so, it certainly can't happen in the 1.2.x series. That'd be great. As you can see from the chosen severity, this is nothing I find too pressing. It's just, that I suspect others might encounter this problem too and in the long run it might be easier to just change one side. But this is absolutely your call and if you prefer not to do this, then tag #651696 wontfix and I forward the appropriate changes to QApt's upstream. Kind regards, Kai Wasserbäch -- E-Mail: cu...@debian.org IRC: Curan Jabber: dri...@debianforum.de URL: http://wiki.debian.org/C%C3%B9ran GnuPG: 0xE1DE59D2 0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2 signature.asc Description: OpenPGP digital signature
