[zeromq-dev] Idiot guide to update mlm server project
opedroso at gmail.com
Mon Apr 11 02:49:50 CEST 2016
The way we do is to fork zeromq/zproject to matjz/zproject, push your
change to matjaz/zproject and then request a PR to zeromq/zproject from
Sine you ran zproject/tstgenbld.sh already you know there are no problems.
There id no need, but I would mention that you ran and the results were
good. This may help somebody else down the line when reading your comments.
On Sun, Apr 10, 2016, 18:01 Matjaž Ostroveršnik <
matjaz.ostroversnik at gmail.com> wrote:
> Thanks Osiris.
> I did it. Difference before and after is only in timestamps at the end,
> so I believe it is ok.
> The change is minimal:
> - added comments (how to build out of source & work with eclipse
> - commented lines which caused the in source build
> I comit the zproject_cmake.gsl
> Can't git push.
> What should I to do next, to finalize?
> I'd like to go full circle, before I apply the curve patch.
> Thanks in advance
> On 10.4.2016 3:03, Osiris Pedroso wrote:
> > Matjaz, checkout the zproject/tstgenbld.sh script.
> > It does the generation, build and make test for a list of projects
> (czmq, malamute, zyre).
> > I think it would be simple to add some cmake targets to regen the
> sources if zproject and gsl projects are on disk.
> > As long as we don't wire to do it automatically as Pieter prefers, I
> think it would be great to have it available for us newbies.
> > Sent from my iPad. Regularly foiled by autocorrect. But duck it..
> >> On Apr 9, 2016, at 14:35, Pieter Hintjens <ph at imatix.com> 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
> >> * A tool that generates man pages from sources (mkman)
> >> * A tool that generates server/client classes from state machine models
> >> * 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
> >>> 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->...) .
> >>> 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
> >>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev