Bug#409953: /usr/bin/moc must not be handled by alternatives
Matthias Klose <firstname.lastname@example.org> 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
Captain Logic is not steering this tugboat.