<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Christopher<br>
<br>
I don't think this is that much necessary, but I thought it was the<br>
less ugly way at that time. If I recall correctly, one of the main
factors<br>
was that protobuf compiler can't place compiled files other that
where<br>
the original *.proto file is situated, and I was not happy about
that way<br>
of system pollution.<br>
<br>
I would highly appreciate if you could fix it in a nice way.<br>
<br>
Thanks,<br>
Ruslan<br>
<br>
<div class="moz-cite-prefix">On 08/11/2015 08:32 PM, Christopher
Covington wrote:<br>
</div>
<blockquote cite="mid:55CA31B3.8010600@codeaurora.org" type="cite">
<pre wrap="">On 01/19/2015 09:10 AM, Ruslan Kuprieiev wrote:
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap=""><span class="moz-txt-citetags">> </span>Pavel reported that decimal values for some fields are hard to read,
<span class="moz-txt-citetags">> </span>because people used to see hex values in there. Unfortunately, json
<span class="moz-txt-citetags">> </span>doesn't support hex representation of integers, so we can only store
<span class="moz-txt-citetags">> </span>them as hex strings. Not all field need to be represented as hex
<span class="moz-txt-citetags">> </span>strings, so this set introduces a custom field option called "criu"
<span class="moz-txt-citetags">> </span>to use in our proto files. One should use [(criu).hex = true] to mark
<span class="moz-txt-citetags">> </span>which field should be represented as a hex string. pb2dict module
<span class="moz-txt-citetags">> </span>from pycriu package will look into field options and if he finds that
<span class="moz-txt-citetags">> </span>criu.hex is set to True, it will convert such field to/from hex string.
<span class="moz-txt-citetags">> </span>Though, such behaviour is optional and user can request it by specifying
<span class="moz-txt-citetags">> </span> --format hex when calling crit decode("crit encode" in its turn, detects
<span class="moz-txt-citetags">> </span>such fields automatically and doesn't require any special cmdline options
<span class="moz-txt-citetags">> </span>to be set).
<span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>We need our proto files to compile with both protoc and
<span class="moz-txt-citetags">> </span>protoc-c compilers, which requires creating google/protobuf
<span class="moz-txt-citetags">> </span>directory with a symlink to <i class="moz-txt-slash"><span class="moz-txt-tag">/</span>usr/include/google/protobuf<span class="moz-txt-tag">/</span></i>
<span class="moz-txt-citetags">> </span>descriptor.proto to make protoc-c and generated c files happy.
</pre>
</blockquote>
<pre wrap="">This is not a nice presumption, that the user has a distribution package of
protobuf installed at that path, and if they do, that it's the version they
want criu/crit to be built against/use.
Can you please elaborate on why you think this is necessary? We'll probably be
cooking up a patch to change this.
</pre>
</blockquote>
<br>
</body>
</html>