[zeromq-dev] Idiot guide to update mlm server project

[Matjaž Ostroveršnik]

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
> <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
>>
>>> 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
>>> <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.
>>> 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
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev