Hi Matjaz, 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 your fork.
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. Osiris On Sun, Apr 10, 2016, 18:01 Matjaž Ostroveršnik < [email protected]> 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 > > 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 >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
