Matthias Klose <[EMAIL PROTECTED]> writes: > Having both qt3-dev-tools and libqt4-dev results in moc pointing to > moc-qt3 by default. Trying to generate files with moc-qt3 when files > for qt4 are needed results in build errors like: > > ./slotcallbacks.moc.h:13:34: error: private/qucomextra_p.h: No such file or > directory > ./slotcallbacks.moc.h:15:2: error: #error "This file was generated using > the moc from 3.3.7. It" > ./slotcallbacks.moc.h:16:2: error: #error "cannot be used with the include > files from this version of Qt." > ./slotcallbacks.moc.h:17:2: error: #error "(The moc has changed too much.)" > > To reliable build, each package generating files with moc during the > build and build-depending on libqt4-dev must have a build conflict > against qt3-dev-tools. > > Same for packages build-depending on qt3-dev-tools, if you consider > that the alternative can be manually adjusted as well. > > This seems to be a lot of work for many packages; why is moc provided > as an alternative at all? It causes builds to fail, so it isn't an > alternative for many cases.
moc-qt3 and moc-qt4 are able to coexist to an extent so it doesn't seem overly productive to have libqt4-dev and qt3-dev-tools conflict with each other. For example, if you use qmake-qt4, it's smart enough to use moc-qt4. I do development on both Qt3 and Qt4 and would be pretty annoyed if I couldn't have both installed at the same time. However, some other Qt3/Qt4 build systems just rely on the existence of /usr/bin/moc so that's why it's provided through alternatives. I'm not aware of a better solution. We can't just choose to have it always be a link to either moc-qt3 or moc-qt4, since that would break a lot of builds too. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]