[Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

[Oswald Buddenhagen]

On Tue, Jan 10, 2017 at 01:42:12AM +0000, Stottlemyer, Brett (B.S.) wrote:
> The processing of QObject code by repc to generate the .rep input file
> format was added afterwards.  It allows existing Qt header files to be
> used with QtRO with compile time checks.  We don’t use that feature much
> internally, but others are.
> 
you mostly lost me here, because i just don't know enough about the data
flows of the qtro build system, so it would be helpful if you outlined
that.

but my naive understanding of rpc implementations is that you actually
want to create some idl (is this what .rep is about?) from the c++, and
in a later step compile that into stubs and skeletons. the former sounds
like a task moc could do as a side effect, while the latter is for repc.

as it happens, we actually have that in qtbase already, in form of the
dbus tools. and as expected, qdbuscpp2xml is yet another tool that pulls
in moc sources ...

and obviously, moc itself could also be split into two tools.
or, the moc frontend could be replaced with clang, for which code
actually already exists, but wasn't deemed quite ready for prime time
yet. maybe we could actually pull that off now that qdoc is switching
to clang as well.

soliciting input primarily from olivier and thiago here ...

> >  - please verify that improvements to moc and the meta type system have
> >    not obsoleted some repc functionality in the first place.
> 
> Pretty sure that for the primary use case they don’t, but if you can point
> me to specific enhancements to look at, that would be appreciated.
> 
i'll leave it for others to comment on.

> Overall, I can’t quite tell from your response which items are nice to
> have, need to have (by feature freeze) or need to have (by 5.9
> release).  I’d appreciate clarification.
> 
it's in the interest of the qt project to unify the offering as much as
possible, minimizing redundant apis and implementations. the former are
by definition before-freeze items, while the latter are as far as they
cannot be done without impacting the api. (api being used in the
broadest sense here, so tools are obviously also covered.)