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