Packages
gpb
3.12.0
5.0.0
4.21.7
4.21.6
4.21.5
4.21.4
4.21.3
4.21.2
4.21.1
4.21.0
4.20.0
4.19.9
4.19.8
4.19.7
4.19.6
4.19.5
4.19.4
4.19.3
4.19.2
4.19.1
4.19.0
4.18.0
4.17.7
4.17.6
4.17.5
4.17.3
4.17.2
4.17.1
4.17.0
4.16.2
4.16.1
4.16.0
4.15.2
4.15.1
4.14.2
4.14.1
4.14.0
4.13.0
4.12.0
4.11.2
4.11.1
4.11.0
4.10.6
4.10.5
4.10.4
4.10.3
4.10.2
4.10.1
4.10.0
4.9.3
4.9.2
4.9.1
4.9.0
4.8.0
4.7.3
4.7.2
4.7.1
4.7.0
4.6.0
4.5.1
4.5.0
4.4.1
4.4.0
4.3.3
4.3.2
4.3.1
4.3.0
4.2.3
4.2.2
4.2.1
4.2.0
4.1.9
4.1.8
4.1.7
4.1.6
4.1.5
4.1.4
4.1.3
4.1.2
4.1.1
4.1.0
4.0.2
4.0.1
4.0.0
3.28.1
3.28.0
3.27.7
3.27.6
3.27.5
3.27.4
3.27.3
3.27.2
3.27.1
3.27.0
3.26.8
3.26.7
3.26.6
3.26.5
3.26.4
3.26.3
3.26.2
3.26.1
3.26.0
3.25.2
3.25.1
3.25.0
3.24.4
3.24.3
3.24.2
3.24.1
3.24.0
3.23.2
3.23.1
3.23.0
3.22.5
3.22.4
3.22.3
3.22.2
3.22.1
3.22.0
3.21.3
3.21.2
3.21.1
3.21.0
3.20.3
3.20.2
3.20.0
3.19.0
3.18.10
3.18.9
3.18.8
3.18.7
3.18.6
3.18.5
3.18.4
3.18.3
3.18.2
3.18.1
3.18.0
3.17.13
3.17.12
3.17.11
3.17.10
3.17.9
3.17.8
3.17.5
3.17.4
3.17.3
3.17.2
3.17.1
3.17.0
3.16.0
3.15.0
3.14.0
3.13.0
3.12.2
3.12.1
3.12.0
3.11.0
A compiler for Google protocol buffer definitions files for Erlang.
Current section
Files
Jump to
Current section
Files
README.nif-cc
The `nif' option will cause the compiler to generate nif C++ code
for that can be linked with the Google protobuf C++ library.
The purpose for this is speed: the Google protobuf C++ is faster than
the interpreted Erlang code, but will also lock up an Erlang
scheduler for as long as it takes for the Google protobuf library
to complete. This is normally a small amount of time, but can be a
longer time for huge messages. The generated nif code can be
compiled with Erlang R14B or later. The `gpb_compile' will only
generate C++ code, it will _not_ compile the generated C++
code for you. Below is an example of how to generate and compile
the C++ nif code under Linux. Details may differ from system to
system.
# Use protoc to generate C++ code, and compile it.
# This will generate x.pb.cc and x.pb.h from x.proto.
protoc --cpp_out=$PWD x.proto
g++ -g -fPIC -O3 -I/path/to/protobuf-include -o x.pb.o -c x.pb.cc
# Generate Erlang code and C++ nif glue code, and compile it.
# This will generate x.erl, x.hrl and x.nif.cc from x.proto.
erl -boot start_clean -pa /path/to/gpb/ebin -noshell -noinput +B \
-I$PWD -nif -s gpb_compile c x.proto
erlc -Wall x.erl
g++ -g -fPIC -Wall -O3 -I/path/to/protobuf -o x.nif.o -c x.nif.cc
# Link all the C++ code together to a shared library.
g++ -g -fPIC -shared -O3 -Wall -o x.nif.so x.nif.o x.pb.o \
-L/path/to/protobuf-libs -lprotobuf \
-Wl,-rpath=/path/to/protobuf-libs
# Now, if you load x.beam into an Erlang VM, it will
# automatically load x.nif.so which contains the nif glue C++
code as well as the protobuf code.
NB: Caveats: Reloading or upgrading code compiled with the `nif'
option, might have unexpected behaviour. The Google protobuf
library maintains a database of .proto descriptors and will
complain -- and halt the entire Erlang VM -- if you try to load nif
code in two different modules that defines a message with the same
name. I have also seen cases where protobuf descriptors from old
versions of the nif code appears to be used even if new code has
been loaded. The descriptor database appears to be kept as long as
the Google C++ protobuf library is loaded, and it is not possible
to control unloading of a sharerd library in Erlang, at least as of
R15B01. Even if the code has been purged and deleted, the shared
object for the nif, and thus also for the Google protobuf library's
database, may still be kept in memory.
The `load_nif' option lets you specify the code to use to load the nif.
The value to the `load_nif' must be a text that defines the function
`load_nif/0', that in the end calls `erlang:load_nif/2'.
Two special substrings are recognized and substituted in the text:
`{{nifbase}}'
The basename of the nif file to be loaded (a string).
Example: `"MyModule.nif"' if we are compiling `MyModule.proto'.
This is intended to be (part of) the first argument in
the call to `erlang:load_nif/2'.
`{{loadinfo}}'
This is a term that is intended to be the second argument in
the call to `erlang:load_nif/2'.
The default for the `load_nif' is as follows: If the module's
directory, as returned by`code:which/1', is on the form
`/path/to/ebin/Mod.beam', then the nif object code is loaded from
`/path/to/priv/Mod.nif'. Otherwise: if `code:which/1' returns
`/some/path/Mod.beam', then the nif is loaded from
`/some/path/Mod.nif'.