Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(125)

Unified Diff: third_party/protobuf/cmake/README.md

Issue 1322483002: Revert https://codereview.chromium.org/1291903002 (protobuf roll). (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master
Patch Set: Created 5 years, 4 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
« no previous file with comments | « third_party/protobuf/cmake/CMakeLists.txt ('k') | third_party/protobuf/cmake/extract_includes.bat.in » ('j') | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
Index: third_party/protobuf/cmake/README.md
diff --git a/third_party/protobuf/cmake/README.md b/third_party/protobuf/cmake/README.md
deleted file mode 100644
index c68defd8afeb2d09d08f5d3f2f8eae2f09dd544b..0000000000000000000000000000000000000000
--- a/third_party/protobuf/cmake/README.md
+++ /dev/null
@@ -1,139 +0,0 @@
-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 gmock directory exists in the upper level directory. If you
- checkout the code from github via "git clone", this gmock 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 gmock directory included.
-
- You can also download gmock 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 gmock, skip the build of tests by turning off the
- BUILD_TESTING option:
-
- $ cmake -G "Visual 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.
-
« no previous file with comments | « third_party/protobuf/cmake/CMakeLists.txt ('k') | third_party/protobuf/cmake/extract_includes.bat.in » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698