blob: ad342497bbac3218a487912d92297386dec6d0b4 [file] [log] [blame]
temporal40ee5512008-07-10 02:12:20 +00001This directory contains project files for compiling Protocol Buffers using
2MSVC. This is not the recommended way to do Protocol Buffer development --
3we prefer to develop under a Unix-like environment -- but it may be more
4accessible to those who primarily work with MSVC.
5
6Compiling and Installing
7========================
8
Feng Xiao78c82002014-12-11 15:36:08 -080090) Check whether a gtest directory exists in the upper level directory. If
10 you checkout the code from github via "git clone", this gtest directory
11 won't exist and you won't be able to build the tests described below. To
12 avoid this problem consider downloading one of the release tar balls which
13 contains gtest already and copying the gest directory from there to your
14 protobuf directory:
15 https://github.com/google/protobuf/releases
temporal40ee5512008-07-10 02:12:20 +0000161) Open protobuf.sln in Microsoft Visual Studio.
temporalcc930432008-07-21 20:28:30 +0000172) Choose "Debug" or "Release" configuration as desired.*
temporal40ee5512008-07-10 02:12:20 +0000183) From the Build menu, choose "Build Solution". Wait for compiling to finish.
kenton@google.come6607e32009-08-01 01:29:03 +0000194) From a command shell, run tests.exe and lite-test.exe and check that all
20 tests pass.
temporal40ee5512008-07-10 02:12:20 +0000215) Run extract_includes.bat to copy all the public headers into a separate
22 "include" directory (under the top-level package directory).
236) Copy the contents of the include directory to wherever you want to put
24 headers.
kenton@google.com580cf3c2008-10-21 17:18:26 +0000257) Copy protoc.exe wherever you put build tools (probably somewhere in your
26 PATH).
kenton@google.come6607e32009-08-01 01:29:03 +0000278) Copy libprotobuf.lib, libprotobuf-lite.lib, and libprotoc.lib wherever you
28 put libraries.
temporal40ee5512008-07-10 02:12:20 +000029
temporalcc930432008-07-21 20:28:30 +000030* To avoid conflicts between the MSVC debug and release runtime libraries, when
kenton@google.com580cf3c2008-10-21 17:18:26 +000031 compiling a debug build of your application, you may need to link against a
32 debug build of libprotobuf.lib. Similarly, release builds should link against
33 release libs.
temporalcc930432008-07-21 20:28:30 +000034
kenton@google.com9b10f582008-09-30 00:09:40 +000035DLLs vs. static linking
36=======================
37
38Static linking is now the default for the Protocol Buffer libraries. Due to
39issues with Win32's use of a separate heap for each DLL, as well as binary
40compatibility issues between different versions of MSVC's STL library, it is
41recommended that you use static linkage only. However, it is possible to
42build libprotobuf and libprotoc as DLLs if you really want. To do this,
43do the following:
44
45 1) Open protobuf.sln in MSVC.
kenton@google.com9270a992009-08-01 02:16:55 +000046 2) For each of the projects libprotobuf, libprotobuf-lite, and libprotoc, do
47 the following:
kenton@google.com9b10f582008-09-30 00:09:40 +000048 2a) Right-click the project and choose "properties".
49 2b) From the side bar, choose "General", under "Configuration Properties".
50 2c) Change the "Configuration Type" to "Dynamic Library (.dll)".
51 2d) From the side bar, choose "Preprocessor", under "C/C++".
52 2e) Add PROTOBUF_USE_DLLS to the list of preprocessor defines.
53 3) When compiling your project, make sure to #define PROTOBUF_USE_DLLS.
temporal40ee5512008-07-10 02:12:20 +000054
55When distributing your software to end users, we strongly recommend that you
56do NOT install libprotobuf.dll or libprotoc.dll to any shared location.
57Instead, keep these libraries next to your binaries, in your application's
58own install directory. C++ makes it very difficult to maintain binary
59compatibility between releases, so it is likely that future versions of these
kenton@google.com9b10f582008-09-30 00:09:40 +000060libraries will *not* be usable as drop-in replacements.
temporal40ee5512008-07-10 02:12:20 +000061
62If your project is itself a DLL intended for use by third-party software, we
63recommend that you do NOT expose protocol buffer objects in your library's
64public interface, and that you statically link protocol buffers into your
65library.
66
kenton@google.com50ede8b2009-04-27 22:28:10 +000067ZLib support
68============
69
70If you want to include GzipInputStream and GzipOutputStream
71(google/protobuf/io/gzip_stream.h) in libprotoc, you will need to do a few
72additional steps:
73
741) Obtain a copy of the zlib library. The pre-compiled DLL at zlib.net works.
752) Make sure zlib's two headers are in your include path and that the .lib file
76 is in your library path. You could place all three files directly into the
77 vsproject directory to compile libprotobuf, but they need to be visible to
78 your own project as well, so you should probably just put them into the
79 VC shared icnlude and library directories.
803) Right-click on the "tests" project and choose "properties". Navigate the
81 sidebar to "Configuration Properties" -> "Linker" -> "Input".
824) Under "Additional Dependencies", add the name of the zlib .lib file (e.g.
83 zdll.lib). Make sure to update both the Debug and Release configurations.
845) If you are compiling libprotobuf and libprotoc as DLLs (see previous
85 section), repeat steps 2 and 3 for the libprotobuf and libprotoc projects.
86 If you are compiling them as static libraries, then you will need to link
87 against the zlib library directly from your own app.
886) Edit config.h (in the vsprojects directory) and un-comment the line that
89 #defines HAVE_ZLIB. (Or, alternatively, define this macro via the project
90 settings.)
91
temporal40ee5512008-07-10 02:12:20 +000092Notes on Compiler Warnings
93==========================
94
95The following warnings have been disabled while building the protobuf libraries
96and compiler. You may have to disable some of them in your own project as
97well, or live with them.
98
99C4018 - 'expression' : signed/unsigned mismatch
100C4146 - unary minus operator applied to unsigned type, result still unsigned
101C4244 - Conversion from 'type1' to 'type2', possible loss of data.
102C4251 - 'identifier' : class 'type' needs to have dll-interface to be used by
103 clients of class 'type2'
104C4267 - Conversion from 'size_t' to 'type', possible loss of data.
105C4305 - 'identifier' : truncation from 'type1' to 'type2'
106C4355 - 'this' : used in base member initializer list
107C4800 - 'type' : forcing value to bool 'true' or 'false' (performance warning)
108C4996 - 'function': was declared deprecated
109
kenton@google.com9b10f582008-09-30 00:09:40 +0000110C4251 is of particular note, if you are compiling the Protocol Buffer library
111as a DLL (see previous section). The protocol buffer library uses templates in
temporal40ee5512008-07-10 02:12:20 +0000112its public interfaces. MSVC does not provide any reasonable way to export
113template classes from a DLL. However, in practice, it appears that exporting
114templates is not necessary anyway. Since the complete definition of any
115template is available in the header files, anyone importing the DLL will just
116end up compiling instances of the templates into their own binary. The
117Protocol Buffer implementation does not rely on static template members being
118unique, so there should be no problem with this, but MSVC prints warning
119nevertheless. So, we disable it. Unfortunately, this warning will also be
120produced when compiling code which merely uses protocol buffers, meaning you
121may have to disable it in your code too.