Ok .Thanks. On 10.4.2016 20:08, Pieter Hintjens wrote: > See my answer to your previous email. When you want to talk to two > servers (redundancy or failover), use two dealer sockets. In the Guide > this is explained in the Harmony pattern, somewhere near the end. > > On Sun, Apr 10, 2016 at 7:56 PM, Matjaž Ostroveršnik > <[email protected]> wrote: >> >You can build Malamute without knowing anything about zproject. >> Ok. Thanks. That good news. I got information that I need to fix >> something in zproject also. ;-) >> >> >make code >> >>> gsl project.xml >> Ok let's start here and see to where we can come. ;-) >> >> Thanks for help. >> >> BTW. I can't find a file with source code, where DEALER port selects socket >> to write to or read from (in case of multiaddress attach) >> >> Best regards >> >> Matjaž >> >> >> >> On 9.4.2016 21:35, Pieter Hintjens wrote: >>> On Sat, Apr 9, 2016 at 9:00 PM, Matjaž Ostroveršnik >>> <[email protected]> wrote: >>> >>>> "Source" and generated files in our solution are clearly separated and >>>> in different folders. >>> Not possible in our case due to independent layers of code generation, >>> often feeding into each other. >>> >>> E.g. in CZMQ, we have: >>> >>> * A tool that generates the socket option classes (zsock_option.gsl) >>> * A tool that generates the project packaging (zproject packaging targets) >>> * A tool that generates man pages from sources (mkman) >>> * A tool that generates server/client classes from state machine models >>> (zproto) >>> * A tool that generates protocol codecs from protocol models (zproto) >>> * A tool that generates language bindings (zproject again) >>> >>> The outputs of one generator look like "normal" code to higher layers. >>> >>>> What is the top level build command in mlm case, which builds everything >>>> from sources to binaries and tests data? >>> All generated code is saved in the git repository, as you saw. The top >>> level command to rebuild generated models is `make code`, and then >>> `gsl project.xml`. >>> >>>> With mlm one needs to dig into generated sources and read the comments >>>> (I admit the are clearly marked). The problem is that at least one >>>> (maybe more) has two hops or more. (header file->api file->...) . Second >>>> hop was one too much for me. ;-) >>> Yes, sorry. This is the price we pay for abstraction. FWIW the current >>> approach is significantly simpler than we've done in the past. We >>> don't have much meta. >>> >>>> I break the rule by intention (i.e. by updating the generated file), >>>> since I wanted to experiment. The experiment is over and I'd like to put >>>> the changes in proper places. That's the point where I am now, and >>>> unfortunately I am stuck. >>> Hmm. >>> >>>> That was my initial intention (i.e. I changed the CMake file; just few >>>> lines). ;-) >>> So, you need to untangle the various changes and then we can work >>> together to backport each one (if possible, sometimes it won't be). >>> >>> Start with the simplest one. >>> >>>> Can you (actually any of the product veterans): in form of short build >>>> instructions(part of the distribution) >>>> - provide a list of "source" generated files >>> The models are (for our generation) always XML files, sometimes with >>> other extensions. >>> >>> The sources for other generation tools are arbitrary. E.g. >>> CMakeLists.txt, configure.ac, etc. >>> >>>> If the sources and generated files are clearly separated and completely >>>> integrated into the build procedure, then everything above in less >>>> important. >>> Not going to happen, sorry. There are tradeoffs, and one is to make >>> code generation at one level invisible to other levels. That's done on >>> purpose. Malamute has N classes, all in include and src. That's a >>> contract with all build tools that work on the project. Whether or not >>> some of those classes, or pieces of them, are generated is an internal >>> decision. It cannot be exposed at the structural level or we add >>> significant cost elsewhere, to layers that should not be paying it. >>> >>>> It would be nice if the build procedure... >>>> - would be completely inside the project structure (I understand that >>>> one building the mlm has to work with zproject project files also; >>>> correct me please if I am not right) >>> You can build Malamute without knowing anything about zproject. >>> >>> -Pieter >>> _______________________________________________ >>> zeromq-dev mailing list >>> [email protected] >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
