On 1/9/17, 10:54 AM, "Development on behalf of Oswald Buddenhagen" <development-bounces+bstottle=ford....@qt-project.org on behalf of oswald.buddenha...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development