Bug 756395

If you want to test some fixes or workarounds, you can scratch-build my "swift" package which currently doesn't build in rawhide because of this Qt bug.

Here's the build.log: http://koji.fedoraproject.org/koji/getfile?taskID=3531816&name=build.log

Created attachment 538531 [details]
Workaround

Looking into this.  The problematic part is this line in header boost/type_traits/detail/has_binary_operator.hpp:
> namespace BOOST_JOIN(BOOST_TT_TRAIT_NAME,_impl) {

The trouble is, this header is included several times with differing values of BOOST_TT_TRAIT_NAME, so we can't pre-expand it simply.  But I don't suppose the datum is important in any way to the MOC parser, so in the patch, I just make the whole block invisible to MOC.

But this is in fact a bug in MOC.  The code is correct on boost side.  I'm reassigning this to Qt in hope you guys can patch around this problem yourself.  But if it's somehow a problem, let me know, and I'll turn in the workaround that I attached above.

Here, have this nice reproducer:

#define X(A) A
#define Y a
namespace X(Y) {
  class meh {};
}

$ g++ -c ble.cc
$ moc-qt4 ble.cc
ble.cc:3: Parse error at "X"

Per the upstream bug, an alternative workaround includes:

"Passing the following to moc will prevent it from parsing through the portion of boost that it is having problems with:
-DBOOST_TT_HAS_OPERATOR_HPP_INCLUDED"

Thanks, that's a nice idea.  Jan, does that seem like an acceptable workaround to you?  That would hide from MOC the whole boost/type_traits/has_operator.hpp that drags in the problematic headers.  That would be preferred from my point of view--if we are introducing a kludge, let's do it in the least exposed place.

A quick hack might be to predefine that macro in MOC, at the same place where QT_MOC_RUN is being predefined at.

The problem is that MOC's C++ parser is quite dumb, it only parses a subset of C++, ignores everything else, and occasionally chokes on something. AFAIK, it doesn't actually do preprocessor expansion at all (and in fact that's sometimes a way to sneak unsupported constructs past MOC, e.g.
"#define foo foo __attribute__((unused))").

(To clarify my example: MOC will normally just ignore function prototypes and variable declarations entirely, and thus not choke on that attribute, but if you want to put an __attribute__((unused)) on a parameter is a Qt slot, it at least used to not like it.)

I've tested building swift with "moc-qt4 -DBOOST_TT_HAS_OPERATOR_HPP_INCLUDED" and it worked properly. I will use this workaround for now to get rid of those "Broken dependencies" emails.

IMHO, littering all packages with this workaround is a very bad idea.

I'm looking into patching MOC to predefine that symbol.

I added this patch:
http://pkgs.fedoraproject.org/gitweb/?p=qt.git;a=blob;f=qt-everywhere-opensource-src-4.8.0-rc1-moc-boost148.patch;h=f0ce6564e29e22eac504c538698517bdcef80061;hb=060db3c767b670dc1e168252644c937abc9fe607
to qt-4.8.0-0.27.rc1.fc17, which is now building in Rawhide. I can also add the same workaround to qt3.

This is now fixed in Rawhide with my 1-line workaround, I'll leave it to the upstreams to come up with a cleaner fix.

As for qt3, its MOC had a different parser, so I'm only going to patch things if we know it's also affected.

Removing external tracker bug with the id '22829' as it is not valid for this tracker