[zeromq-dev] Idiot guide to update mlm server project
matjaz.ostroversnik at gmail.com
Sun Apr 10 19:56:37 CEST 2016
>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. ;-)
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)
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
More information about the zeromq-dev