qt moc and int64_t

["Ian D. Leroux" <idleroux%fastmail.fm@localhost>]

multimedia/vlc21 and now wip/vlc use a number of patches (listed at the
end of this message) to rename int64_t to putime_t in the arguments of
slots and signals.  Although I don't know for sure why this was done
originally, it has the useful effect of preventing runtime error
messages such as the following:

Object::connect: No such signal InputManager::resumePlayback(__int64_t) in main_interface.cpp:402

(the class and method vary, the "Object::connect: No such signal" part
is constant).  My current best guess (and it is only a guess; I haven't
touched any qt code before this), is that the preprocessor used by qt
to do all the slot/signal connecting doesn't know about int64_t, and
therefore can't match slots and signals that have int64_t arguments.
By introducing a new type with an explicit definition
(typedef int64_t putime_t) where the preprocessor can see it, the
patches give the slots and signal recognizable types and get the
slot/signal mechanism working again.

As wiedi@ pointed out to me a few days ago, it would be much nicer to
fix this by making the qt preprocessor aware of standard integer
types.  I'm not sure if this is a problem in our qt infrastructure or
whether wip/vlc is failing to include some standard system header where
int64_t is declared.

Has anyone seen anything like this in other packages?  Anyone with some
knowledge of qt care to chime in on the plausibility of my guess?

Examples of the patches I mean, all of these are in wip/vlc/patches:

patch-modules_gui_qt4_components_controller.cpp
patch-modules_gui_qt4_components_extended__panels.cpp
patch-modules_gui_qt4_components_interface__widgets.cpp
patch-modules_gui_qt4_components_interface__widgets.hpp
patch-modules_gui_qt4_input__manager.cpp
patch-modules_gui_qt4_input__manager.hpp
patch-modules_gui_qt4_main__interface.cpp
patch-modules_gui_qt4_main__interface.hpp
patch-modules_gui_qt4_util_input__slider.cpp
patch-modules_gui_qt4_util_input__slider.hpp

This hack works, but it would be nice to get rid of it.

--
IDL