[zeromq-dev] Idiot guide to update mlm server project
ph at imatix.com
Sun Apr 10 20:08:32 CEST 2016
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
<matjaz.ostroversnik at gmail.com> 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
> 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
> On 9.4.2016 21:35, Pieter Hintjens wrote:
>> On Sat, Apr 9, 2016 at 9:00 PM, Matjaž Ostroveršnik
>> <matjaz.ostroversnik at gmail.com> 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.
>>> 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
>> 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.
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev