Arrow uses CMake as a build configuration system. Currently, it supports in-source and out-of-source builds with the latter one being preferred.
Arrow requires a C++11-enabled compiler. On Linux, gcc 4.8 and higher should be sufficient.
To build the thirdparty build dependencies, run:
./thirdparty/download_thirdparty.sh ./thirdparty/build_thirdparty.sh source ./thirdparty/set_thirdparty_env.sh
You can also run from the root of the C++ tree
source setup_build_env.sh
Arrow is configured to use the thirdparty directory by default for its build dependencies. To set up a custom toolchain see below.
Simple debug build:
mkdir debug cd debug cmake .. make unittest
Simple release build:
mkdir release cd release cmake .. -DCMAKE_BUILD_TYPE=Release make unittest
Detailed unit test logs will be placed in the build directory under build/test-logs.
Follow the directions for simple build except run cmake with the --ARROW_BUILD_BENCHMARKS parameter set correctly:
cmake -DARROW_BUILD_BENCHMARKS=ON ..
and instead of make unittest run either make; ctest to run both unit tests and benchmarks or make runbenchmark to run only the benchmark tests.
Benchmark logs will be placed in the build directory under build/benchmark-logs.
To set up your own specific build toolchain, here are the relevant environment variables
GTEST_HOME (only required to build the unit tests)GBENCHMARK_HOME (only required if building benchmarks)FLATBUFFERS_HOME (only required for the IPC extensions)Pull requests are run through travis-ci for continuous integration. You can avoid build failures by running the following checks before submitting your pull request:
make unittest make lint # The next two commands may change your code. It is recommended you commit # before running them. make clang-tidy # requires clang-tidy is installed make format # requires clang-format is installed
Note that the clang-tidy target may take a while to run. You might consider running clang-tidy separately on the files you have added/changed before invoking the make target to reduce iteration time. Also, it might generate warnings that aren‘t valid. To avoid these you can use add a line comment // NOLINT. If
NOLINT doesn’t suppress the warnings, you add the file in question to the .clang-tidy-ignore file. This will allow make check-clang-tidy to pass in travis-CI (but still surface the potential warnings in make clang-tidy). Ideally, both of these options would be used rarely. Current known uses-cases whent hey are required: