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

Pieter Hintjens ph at imatix.com
Sat Apr 9 21:35:24 CEST 2016

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
> 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.


More information about the zeromq-dev mailing list