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