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

[Stottlemyer, Brett (B.S.)]

On 1/9/17, 10:54 AM, "Development on behalf of Oswald Buddenhagen" <development-bounces+bstottle=ford.com at qt-project.org on behalf of oswald.buddenhagen at qt.io> wrote:



>i had a quick look at the repo:
>- there is still copy of moc's c++ parser in there. not much to do about
>  it at this point, except that repc is mostly redundant with moc to
>  start with.

This is a direction I hadn’t really considered.  I don’t like duplicating
moc code, but my thought was to put repc into qtbase (if that would be
accepted.  Thiago?) and keep the rest of QtRO in a separate repository.

The primary job of repc is to generate QObject code, and the mkspecs add
those automatically for moc processing.  I.e, it takes the API definition,
in .rep format, and generates an asymmetric pair of files, one for the
Source and one for the Replica.

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.

>  - why not make it an output mode of moc? or at least, it would seem
>    sensible to make moc output an intermediate json file with the meta
>    info it extracted, and still leave the code generation to repc -
>    that would remove the double parsing, and always ensure consistency.

If you are willing to take the .rep format as a moc input (?) this might
work.  If your thought is to take a QObject header file as input, I’m not
sure it does.  As a concrete example, Q_PROPERTY on the Source side can be
CONSTANT, but on the Replica side it can’t (it can have a default value
which is then updated when the connection to the Source is established.)
This asymmetry seems like it would be very confusing if it was output by
moc.

>  - i see that repc creates qdatastream operators for q_enums & co. -
>    that *really* seems like generic moc stuff.

Only in certain cases.  It lets moc handle this if possible.  I’ll have to
look at this again, the intent was to let moc do as much as possible.

>  - 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.

>- was that promised discussion vs. qtsystems actually ever had?

No, but I don’t remember promising to have the discussion.  I know there
was a proposal to look for commonality with web sockets.  That didn’t
happen either.  Are these blockers?

>- formalities:
>  - lots of build system hacks for obsolete qt versions

To be honest, Ossi, you see stuff instantly that I need to study in the
build system.  We can keep working on it, but patches would be welcomed.

>  - lagging in coding style practice (replace foreach, other c++11
>    stuff)

Yes, we have been on LTS, so there are necessary changes for 5.7+.  Are
these needed before feature freeze?  Or can they be addressed as we move
to 5.9?

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.

Thanks, and thanks for the review,
Brett