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 <p...@imatix.com> wrote: > > On Sat, Apr 9, 2016 at 9:00 PM, Matjaž Ostroveršnik > <matjaz.ostrovers...@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@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
