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
