1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
|
This directory contains cmake files that can be used to generate MSVC project
files in order to build protobuf on windows. You need to have cmake installed
on your computer before proceeding.
Compiling and Installing
========================
1. Check whether a gtest directory exists in the upper level directory. If you
checkout the code from github via "git clone", this gtest directory won't
exist and you won't be able to build protobuf unit-tests. Consider using one
of the release tar balls instead:
https://github.com/google/protobuf/releases
These release tar balls are more stable versions of protobuf and already
have the gtest directory included.
You can also download gtest by yourself and put it in the right place.
If you absolutely don't want to build and run protobuf unit-tests, skip
this step and use protobuf at your own risk.
2. Use cmake to generate MSVC project files. Running the following commands
in a command shell will generate project files for Visual Studio 2008 in
a sub-directory named "build".
$ cd path/to/protobuf/cmake
$ mkdir build
$ cd build
$ cmake -G "Visual Studio 9 2008" ..
If you don't have gtest, skip the build of tests by turning off the
BUILD_TESTING option:
$ cmake -G "Visutal Studio 9 2008" -DBUILD_TESTING=OFF ..
3. Open the generated protobuf.sln file in Microsoft Visual Studio.
4. Choose "Debug" or "Release" configuration as desired.
5. From the Build menu, choose "Build Solution". Wait for compiling to finish.
6. If you have built tests, run tests.exe and lite-test.exe from a command
shell and check that all tests pass. Make sure you have changed the working
directory to the output directory because tests.exe will try to find and run
test_plugin.exe in the working directory.
7. Run extract_includes.bat to copy all the public headers into a separate
"include" directory. This batch script can be found along with the generated
protobuf.sln file in the same directory.
8. Copy the contents of the include directory to wherever you want to put
headers.
9. Copy protoc.exe wherever you put build tools (probably somewhere in your
PATH).
10. Copy libprotobuf.lib, libprotobuf-lite.lib, and libprotoc.lib wherever you
put libraries.
To avoid conflicts between the MSVC debug and release runtime libraries, when
compiling a debug build of your application, you may need to link against a
debug build of libprotobuf.lib. Similarly, release builds should link against
release libs.
DLLs vs. static linking
=======================
Static linking is now the default for the Protocol Buffer libraries. Due to
issues with Win32's use of a separate heap for each DLL, as well as binary
compatibility issues between different versions of MSVC's STL library, it is
recommended that you use static linkage only. However, it is possible to
build libprotobuf and libprotoc as DLLs if you really want. To do this,
do the following:
1. Add an additional flag "-DBUILD_SHARED_LIBS=ON" when invoking cmake:
$ cmake -G "Visual Studio 9 2008" -DBUILD_SHARED_LIBS=ON ..
2. Follow the same steps as described in the above section.
3. When compiling your project, make sure to #define PROTOBUF_USE_DLLS.
When distributing your software to end users, we strongly recommend that you
do NOT install libprotobuf.dll or libprotoc.dll to any shared location.
Instead, keep these libraries next to your binaries, in your application's
own install directory. C++ makes it very difficult to maintain binary
compatibility between releases, so it is likely that future versions of these
libraries will *not* be usable as drop-in replacements.
If your project is itself a DLL intended for use by third-party software, we
recommend that you do NOT expose protocol buffer objects in your library's
public interface, and that you statically link protocol buffers into your
library.
ZLib support
============
If you want to include GzipInputStream and GzipOutputStream
(google/protobuf/io/gzip_stream.h) in libprotobuf, you will need to do a few
additional steps:
1. Obtain a copy of the zlib library. The pre-compiled DLL at zlib.net works.
2. Make sure zlib's two headers are in your include path and that the .lib file
is in your library path. You could place all three files directly into this
cmake directory to compile libprotobuf, but they need to be visible to
your own project as well, so you should probably just put them into the
VC shared icnlude and library directories.
3. Add flag "-DZLIB=ON" when invoking cmake:
$ cmake -G "Visual Studio 9 2008" -DZLIB=ON ..
If it reports NOTFOUND for zlib_include or zlib_lib, you might haven't put
the headers or the .lib file in the right directory.
4) Open the generated protobuf.sln file and build as usual.
Notes on Compiler Warnings
==========================
The following warnings have been disabled while building the protobuf libraries
and compiler. You may have to disable some of them in your own project as
well, or live with them.
* C4018 - 'expression' : signed/unsigned mismatch
* C4146 - unary minus operator applied to unsigned type, result still unsigned
* C4244 - Conversion from 'type1' to 'type2', possible loss of data.
* C4251 - 'identifier' : class 'type' needs to have dll-interface to be used by
clients of class 'type2'
* C4267 - Conversion from 'size_t' to 'type', possible loss of data.
* C4305 - 'identifier' : truncation from 'type1' to 'type2'
* C4355 - 'this' : used in base member initializer list
* C4800 - 'type' : forcing value to bool 'true' or 'false' (performance warning)
* C4996 - 'function': was declared deprecated
C4251 is of particular note, if you are compiling the Protocol Buffer library
as a DLL (see previous section). The protocol buffer library uses templates in
its public interfaces. MSVC does not provide any reasonable way to export
template classes from a DLL. However, in practice, it appears that exporting
templates is not necessary anyway. Since the complete definition of any
template is available in the header files, anyone importing the DLL will just
end up compiling instances of the templates into their own binary. The
Protocol Buffer implementation does not rely on static template members being
unique, so there should be no problem with this, but MSVC prints warning
nevertheless. So, we disable it. Unfortunately, this warning will also be
produced when compiling code which merely uses protocol buffers, meaning you
may have to disable it in your code too.
|
