On 1/10/17, 7:11 AM, "Development on behalf of Oswald Buddenhagen" <development-bounces+bstottle=ford....@qt-project.org on behalf of oswald.buddenha...@qt.io> wrote:
>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. Sure. I guess to start off, I don’t consider QtRO to be a RPC mechanism. In my mind, RPC would be akin to exposing a QObject’s slots for calling individually. With QtRO (which only works Qt to Qt, it isn’t currently available to other “languages”, like ruby/python/etc.) you talk QObjects. A Source object is added to the network, and clients (although I’m not sure that is the right term) can then get a Replica of that object. Any change to the Source object (Signals emitted, or Q_Properties changed) then get communicated to every Replica. A Slot call is passed back to the Source for handling, with any “side-effects” forwarded to all Replicas. With this picture in mind, the key to getting it to work is to hook into qt_metacall and pass the invocations between processes. This takes custom code, so QtRO has repc (REPlica Compiler) for this. It reads a .rep file, a simple text format for describing the object’s API via Signals, Slot, Properties and Enums, and generates a Qt header file for the Source and Replica sides. The mkspecs then add these files for moc to process. At some level, I see the .rep format as an extreme of a Q_OBJECT definition in that only the “API” is defined (property, signal, slot, enum), and everything else is private/pimpl. Specific to QtRO, the Source may differ from the Replica in that Q_PROPERTYs may be CONSTANT on the Source, but still have a notify on the Replica. The reason for this is that we want Replica objects to have default values for properties that are valid before the connection is established, and then pick up the “real” value once the connection is made. >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. I see it as the opposite for QtRO. The .rep defines the API, repc creates the Qt headers for the types, then moc generates the code based on the headers. >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. I'm interested to know if you think this is still relevant based on my reply. I’m not really sure how to answer. >soliciting input primarily from olivier and thiago here ... Welcomed. >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.) Completely agree. At the same time, I don’t want to miss the deadline for feature freeze, so I’m hoping to get past that hurdle and address some of your proposals afterwards as a tech preview. As a playground project I think we haven’t gotten a lot of attention from The Qt Company and I really do welcome that. The repc tool specifically is kind of in a weird spot. I’m not sure there are any other tools that are bootstrapped and aren’t in qtbase. Should repc* not be bootstrapped? Alternatively, should it be part of qtbase (so moc doesn’t need to be “3rdParty”)? Until QtRO is promoted to a Qt module, I don’t think these questions can really be answered. *QtRO will do type checking at compile time if an API gets generated from repc. You can also “share” any QObject via QtRO, but the Replica is then dynamically generated and needs runtime checks. The repc program includes moc to it can generate a .rep file for any Qobject - thus supporting compile time checks from existing Qt header files. Oddly enough, the generated code is then passed through moc again. This is the “second” use-case I mentioned. I think it is a valid use case, but one I don’t use much. Hope that helps, Brett _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
