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