Bug#409953: /usr/bin/moc must not be handled by alternatives

[Brian Nelson <pyro@debian.org>]

Matthias Klose <doko@cs.tu-berlin.de> 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.