couchbase 3.0.0.alpha.3-universal-darwin-19 → 3.0.1-universal-darwin-19

data/ext/third_party/snappy/.appveyor.yml

@@ -1,36 +0,0 @@
-# Build matrix / environment variables are explained on:
-# https://www.appveyor.com/docs/appveyor-yml/
-# This file can be validated on: https://ci.appveyor.com/tools/validate-yaml
-
-version: "{build}"
-
-environment:
-  matrix:
-    # AppVeyor currently has no custom job name feature.
-    # http://help.appveyor.com/discussions/questions/1623-can-i-provide-a-friendly-name-for-jobs
-    - JOB: Visual Studio 2019
-      APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2019
-      CMAKE_GENERATOR: Visual Studio 16 2019
-
-platform:
-  - x86
-  - x64
-
-configuration:
-  - RelWithDebInfo
-  - Debug
-
-build_script:
-  - git submodule update --init --recursive
-  - mkdir build
-  - cd build
-  - if "%platform%"=="x86" (set CMAKE_GENERATOR_PLATFORM="Win32")
-      else (set CMAKE_GENERATOR_PLATFORM="%platform%")
-  - cmake --version
-  - cmake .. -G "%CMAKE_GENERATOR%" -A "%CMAKE_GENERATOR_PLATFORM%"
-      -DCMAKE_CONFIGURATION_TYPES="%CONFIGURATION%" -DSNAPPY_REQUIRE_AVX2=ON
-  - cmake --build . --config %CONFIGURATION%
-  - cd ..
-
-test_script:
-  - build\%CONFIGURATION%\snappy_unittest

data/ext/third_party/snappy/.gitignore

@@ -1,8 +0,0 @@
-# Editors.
-*.sw*
-.vscode
-.DS_Store
-
-# Build directory.
-build/
-out/

data/ext/third_party/snappy/.travis.yml

@@ -1,98 +0,0 @@
-# Build matrix / environment variables are explained on:
-# http://about.travis-ci.org/docs/user/build-configuration/
-# This file can be validated on: http://lint.travis-ci.org/
-
-language: cpp
-dist: bionic
-osx_image: xcode11.3
-
-compiler:
-- gcc
-- clang
-os:
-- linux
-- osx
-
-env:
-- BUILD_TYPE=Debug CPU_LEVEL=AVX
-- BUILD_TYPE=Debug CPU_LEVEL=AVX2
-- BUILD_TYPE=RelWithDebInfo CPU_LEVEL=AVX
-- BUILD_TYPE=RelWithDebInfo CPU_LEVEL=AVX2
-
-jobs:
-  exclude:
-  # Travis OSX servers seem to run on pre-Haswell CPUs. Attempting to use AVX2
-  # results in crashes.
-  - env: BUILD_TYPE=Debug CPU_LEVEL=AVX2
-    os: osx
-  - env: BUILD_TYPE=RelWithDebInfo CPU_LEVEL=AVX2
-    os: osx
-  allow_failures:
-  # Homebrew's GCC is currently broken on XCode 11.
-  - compiler: gcc
-    os: osx
-
-addons:
-  apt:
-    sources:
-    - sourceline: 'deb http://apt.llvm.org/bionic/ llvm-toolchain-bionic-10 main'
-      key_url: 'https://apt.llvm.org/llvm-snapshot.gpg.key'
-    - sourceline: 'ppa:ubuntu-toolchain-r/test'
-    packages:
-    - clang-10
-    - cmake
-    - gcc-9
-    - g++-9
-    - ninja-build
-  homebrew:
-    packages:
-    - cmake
-    - gcc@9
-    - llvm@10
-    - ninja
-    update: true
-
-install:
-# The following Homebrew packages aren't linked by default, and need to be
-# prepended to the path explicitly.
-- if [ "$TRAVIS_OS_NAME" = "osx" ]; then
-    export PATH="$(brew --prefix llvm)/bin:$PATH";
-  fi
-# Fuzzing is only supported on Clang. Perform fuzzing on Debug builds.
-- if [ "$CXX" = "clang++" ] && [ "$BUILD_TYPE" = "Debug" ]; then
-    export FUZZING=1;
-  else
-    export FUZZING=0;
-  fi
-# /usr/bin/gcc points to an older compiler on both Linux and macOS.
-- if [ "$CXX" = "g++" ]; then export CXX="g++-9" CC="gcc-9"; fi
-# /usr/bin/clang points to an older compiler on both Linux and macOS.
-#
-# Homebrew's llvm package doesn't ship a versioned clang++ binary, so the values
-# below don't work on macOS. Fortunately, the path change above makes the
-# default values (clang and clang++) resolve to the correct compiler on macOS.
-- if [ "$TRAVIS_OS_NAME" = "linux" ]; then
-    if [ "$CXX" = "clang++" ]; then export CXX="clang++-10" CC="clang-10"; fi;
-  fi
-- echo ${CC}
-- echo ${CXX}
-- ${CXX} --version
-- cmake --version
-
-before_script:
-- mkdir -p build && cd build
-- cmake .. -G Ninja -DCMAKE_BUILD_TYPE=$BUILD_TYPE
-    -DSNAPPY_REQUIRE_${CPU_LEVEL}=ON -DSNAPPY_FUZZING_BUILD=${FUZZING}
-    -DCMAKE_INSTALL_PREFIX=$HOME/.local
-- cmake --build .
-- cd ..
-
-script:
-- build/snappy_unittest
-- if [ -f build/snappy_compress_fuzzer ]; then
-    build/snappy_compress_fuzzer -runs=1000 -close_fd_mask=3;
-  fi
-- if [ -f build/snappy_uncompress_fuzzer ]; then
-    build/snappy_uncompress_fuzzer -runs=1000 -close_fd_mask=3;
-  fi
-- cd build && cmake --build . --target install

data/ext/third_party/snappy/AUTHORS

@@ -1 +0,0 @@
-opensource@google.com

data/ext/third_party/snappy/CONTRIBUTING.md

@@ -1,26 +0,0 @@
-# How to Contribute
-
-We'd love to accept your patches and contributions to this project. There are
-just a few small guidelines you need to follow.
-
-## Contributor License Agreement
-
-Contributions to this project must be accompanied by a Contributor License
-Agreement. You (or your employer) retain the copyright to your contribution,
-this simply gives us permission to use and redistribute your contributions as
-part of the project. Head over to <https://cla.developers.google.com/> to see
-your current agreements on file or to sign a new one.
-
-You generally only need to submit a CLA once, so if you've already submitted one
-(even if it was for a different project), you probably don't need to do it
-again.
-
-## Code reviews
-
-All submissions, including submissions by project members, require review. We
-use GitHub pull requests for this purpose. Consult
-[GitHub Help](https://help.github.com/articles/about-pull-requests/) for more
-information on using pull requests.
-
-Please make sure that all the automated checks (CLA, AppVeyor, Travis) pass for
-your pull requests. Pull requests whose checks fail may be ignored.

data/ext/third_party/snappy/NEWS

@@ -1,188 +0,0 @@
-Snappy v1.1.8, January 15th 2020:
-
-  * Small performance improvements.
-
-  * Removed snappy::string alias for std::string.
-
-  * Improved CMake configuration.
-
-Snappy v1.1.7, August 24th 2017:
-
-  * Improved CMake build support for 64-bit Linux distributions.
-
-  * MSVC builds now use MSVC-specific intrinsics that map to clzll.
-
-  * ARM64 (AArch64) builds use the code paths optimized for 64-bit processors.
-
-Snappy v1.1.6, July 12th 2017:
-
-This is a re-release of v1.1.5 with proper SONAME / SOVERSION values.
-
-Snappy v1.1.5, June 28th 2017:
-
-This release has broken SONAME / SOVERSION values. Users of snappy as a shared
-library should avoid 1.1.5 and use 1.1.6 instead. SONAME / SOVERSION errors will
-manifest as the dynamic library loader complaining that it cannot find snappy's
-shared library file (libsnappy.so / libsnappy.dylib), or that the library it
-found does not have the required version. 1.1.6 has the same code as 1.1.5, but
-carries build configuration fixes for the issues above.
-
-  * Add CMake build support. The autoconf build support is now deprecated, and
-    will be removed in the next release.
-
-  * Add AppVeyor configuration, for Windows CI coverage.
-
-  * Small performance improvement on little-endian PowerPC.
-
-  * Small performance improvement on LLVM with position-independent executables.
-
-  * Fix a few issues with various build environments.
-
-Snappy v1.1.4, January 25th 2017:
-
-  * Fix a 1% performance regression when snappy is used in PIE executables.
-
-  * Improve compression performance by 5%.
-
-  * Improve decompression performance by 20%.
-
-Snappy v1.1.3, July 6th 2015:
-
-This is the first release to be done from GitHub, which means that
-some minor things like the ChangeLog format has changed (git log
-format instead of svn log).
-
-  * Add support for Uncompress() from a Source to a Sink.
-
-  * Various minor changes to improve MSVC support; in particular,
-    the unit tests now compile and run under MSVC.
-
-
-Snappy v1.1.2, February 28th 2014:
-
-This is a maintenance release with no changes to the actual library
-source code.
-
-  * Stop distributing benchmark data files that have unclear
-    or unsuitable licensing.
-
-  * Add support for padding chunks in the framing format.
-
-
-Snappy v1.1.1, October 15th 2013:
-
-  * Add support for uncompressing to iovecs (scatter I/O).
-    The bulk of this patch was contributed by Mohit Aron.
-
-  * Speed up decompression by ~2%; much more so (~13-20%) on
-    a few benchmarks on given compilers and CPUs.
-
-  * Fix a few issues with MSVC compilation.
-
-  * Support truncated test data in the benchmark.
-
-
-Snappy v1.1.0, January 18th 2013:
-
-  * Snappy now uses 64 kB block size instead of 32 kB. On average,
-    this means it compresses about 3% denser (more so for some
-    inputs), at the same or better speeds.
-
-  * libsnappy no longer depends on iostream.
-
-  * Some small performance improvements in compression on x86
-    (0.5–1%).
-
-  * Various portability fixes for ARM-based platforms, for MSVC,
-    and for GNU/Hurd.
-
-
-Snappy v1.0.5, February 24th 2012:
-
-  * More speed improvements. Exactly how big will depend on
-    the architecture:
-
-    - 3–10% faster decompression for the base case (x86-64).
-
-    - ARMv7 and higher can now use unaligned accesses,
-      and will see about 30% faster decompression and
-      20–40% faster compression.
-
-    - 32-bit platforms (ARM and 32-bit x86) will see 2–5%
-      faster compression.
-
-    These are all cumulative (e.g., ARM gets all three speedups).
-
-  * Fixed an issue where the unit test would crash on system
-    with less than 256 MB address space available,
-    e.g. some embedded platforms.
-
-  * Added a framing format description, for use over e.g. HTTP,
-    or for a command-line compressor. We do not have any
-    implementations of this at the current point, but there seems
-    to be enough of a general interest in the topic.
-    Also make the format description slightly clearer.
-
-  * Remove some compile-time warnings in -Wall
-    (mostly signed/unsigned comparisons), for easier embedding
-    into projects that use -Wall -Werror.
-
-
-Snappy v1.0.4, September 15th 2011:
-
-  * Speeded up the decompressor somewhat; typically about 2–8%
-    for Core i7, in 64-bit mode (comparable for Opteron).
-    Somewhat more for some tests, almost no gain for others.
-  
-  * Make Snappy compile on certain platforms it didn't before
-    (Solaris with SunPro C++, HP-UX, AIX).
-
-  * Correct some minor errors in the format description.
-
-
-Snappy v1.0.3, June 2nd 2011:
-
-  * Speeded up the decompressor somewhat; about 3-6% for Core 2,
-    6-13% for Core i7, and 5-12% for Opteron (all in 64-bit mode).
-
-  * Added compressed format documentation. This text is new,
-    but an earlier version from Zeev Tarantov was used as reference.
-
-  * Only link snappy_unittest against -lz and other autodetected
-    libraries, not libsnappy.so (which doesn't need any such dependency).
-
-  * Fixed some display issues in the microbenchmarks, one of which would
-    frequently make the test crash on GNU/Hurd.
-
-
-Snappy v1.0.2, April 29th 2011:
-
-  * Relicense to a BSD-type license.
-
-  * Added C bindings, contributed by Martin Gieseking.
-
-  * More Win32 fixes, in particular for MSVC.
-
-  * Replace geo.protodata with a newer version.
-
-  * Fix timing inaccuracies in the unit test when comparing Snappy
-    to other algorithms.
-
-
-Snappy v1.0.1, March 25th 2011:
-
-This is a maintenance release, mostly containing minor fixes.
-There is no new functionality. The most important fixes include:
-
-  * The COPYING file and all licensing headers now correctly state that
-    Snappy is licensed under the Apache 2.0 license.
-
-  * snappy_unittest should now compile natively under Windows,
-    as well as on embedded systems with no mmap().
-
-  * Various autotools nits have been fixed.
-
-
-Snappy v1.0, March 17th 2011:
-
-  * Initial version.

data/ext/third_party/snappy/README.md

@@ -1,148 +0,0 @@
-Snappy, a fast compressor/decompressor.
-
-
-Introduction
-============
-
-Snappy is a compression/decompression library. It does not aim for maximum
-compression, or compatibility with any other compression library; instead,
-it aims for very high speeds and reasonable compression. For instance,
-compared to the fastest mode of zlib, Snappy is an order of magnitude faster
-for most inputs, but the resulting compressed files are anywhere from 20% to
-100% bigger. (For more information, see "Performance", below.)
-
-Snappy has the following properties:
-
- * Fast: Compression speeds at 250 MB/sec and beyond, with no assembler code.
-   See "Performance" below.
- * Stable: Over the last few years, Snappy has compressed and decompressed
-   petabytes of data in Google's production environment. The Snappy bitstream
-   format is stable and will not change between versions.
- * Robust: The Snappy decompressor is designed not to crash in the face of
-   corrupted or malicious input.
- * Free and open source software: Snappy is licensed under a BSD-type license.
-   For more information, see the included COPYING file.
-
-Snappy has previously been called "Zippy" in some Google presentations
-and the like.
-
-
-Performance
-===========
-
-Snappy is intended to be fast. On a single core of a Core i7 processor
-in 64-bit mode, it compresses at about 250 MB/sec or more and decompresses at
-about 500 MB/sec or more. (These numbers are for the slowest inputs in our
-benchmark suite; others are much faster.) In our tests, Snappy usually
-is faster than algorithms in the same class (e.g. LZO, LZF, QuickLZ,
-etc.) while achieving comparable compression ratios.
-
-Typical compression ratios (based on the benchmark suite) are about 1.5-1.7x
-for plain text, about 2-4x for HTML, and of course 1.0x for JPEGs, PNGs and
-other already-compressed data. Similar numbers for zlib in its fastest mode
-are 2.6-2.8x, 3-7x and 1.0x, respectively. More sophisticated algorithms are
-capable of achieving yet higher compression rates, although usually at the
-expense of speed. Of course, compression ratio will vary significantly with
-the input.
-
-Although Snappy should be fairly portable, it is primarily optimized
-for 64-bit x86-compatible processors, and may run slower in other environments.
-In particular:
-
- - Snappy uses 64-bit operations in several places to process more data at
-   once than would otherwise be possible.
- - Snappy assumes unaligned 32 and 64-bit loads and stores are cheap.
-   On some platforms, these must be emulated with single-byte loads
-   and stores, which is much slower.
- - Snappy assumes little-endian throughout, and needs to byte-swap data in
-   several places if running on a big-endian platform.
-
-Experience has shown that even heavily tuned code can be improved.
-Performance optimizations, whether for 64-bit x86 or other platforms,
-are of course most welcome; see "Contact", below.
-
-
-Building
-========
-
-You need the CMake version specified in [CMakeLists.txt](./CMakeLists.txt)
-or later to build:
-
-```bash
-mkdir build
-cd build && cmake ../ && make
-```
-
-Usage
-=====
-
-Note that Snappy, both the implementation and the main interface,
-is written in C++. However, several third-party bindings to other languages
-are available; see the [home page](docs/README.md) for more information.
-Also, if you want to use Snappy from C code, you can use the included C
-bindings in snappy-c.h.
-
-To use Snappy from your own C++ program, include the file "snappy.h" from
-your calling file, and link against the compiled library.
-
-There are many ways to call Snappy, but the simplest possible is
-
-```c++
-snappy::Compress(input.data(), input.size(), &output);
-```
-
-and similarly
-
-```c++
-snappy::Uncompress(input.data(), input.size(), &output);
-```
-
-where "input" and "output" are both instances of std::string.
-
-There are other interfaces that are more flexible in various ways, including
-support for custom (non-array) input sources. See the header file for more
-information.
-
-
-Tests and benchmarks
-====================
-
-When you compile Snappy, snappy_unittest is compiled in addition to the
-library itself. You do not need it to use the compressor from your own library,
-but it contains several useful components for Snappy development.
-
-First of all, it contains unit tests, verifying correctness on your machine in
-various scenarios. If you want to change or optimize Snappy, please run the
-tests to verify you have not broken anything. Note that if you have the
-Google Test library installed, unit test behavior (especially failures) will be
-significantly more user-friendly. You can find Google Test at
-
-  https://github.com/google/googletest
-
-You probably also want the gflags library for handling of command-line flags;
-you can find it at
-
-  https://gflags.github.io/gflags/
-
-In addition to the unit tests, snappy contains microbenchmarks used to
-tune compression and decompression performance. These are automatically run
-before the unit tests, but you can disable them using the flag
---run_microbenchmarks=false if you have gflags installed (otherwise you will
-need to edit the source).
-
-Finally, snappy can benchmark Snappy against a few other compression libraries
-(zlib, LZO, LZF, and QuickLZ), if they were detected at configure time.
-To benchmark using a given file, give the compression algorithm you want to test
-Snappy against (e.g. --zlib) and then a list of one or more file names on the
-command line. The testdata/ directory contains the files used by the
-microbenchmark, which should provide a reasonably balanced starting point for
-benchmarking. (Note that baddata[1-3].snappy are not intended as benchmarks; they
-are used to verify correctness in the presence of corrupted data in the unit
-test.)
-
-
-Contact
-=======
-
-Snappy is distributed through GitHub. For the latest version, a bug tracker,
-and other information, see https://github.com/google/snappy.