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.


On Sun, Apr 10, 2016, 18:01 Matjaž Ostroveršnik <matjaz.ostroversnik@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@imatix.com> wrote:
>> On Sat, Apr 9, 2016 at 9:00 PM, Matjaž Ostroveršnik
>> <matjaz.ostroversnik@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

zeromq-dev mailing list