This change updates the AVRO CMake module to use the C++ Avro library
when USE_AVRO_CPP is set to true. This is the next step towards Avro
backend update.
Building with the C++ library fails at this point.
Testing:
- Manually tested configuring the project with USE_AVRO_CPP
Change-Id: I0a81c3f7ab5a6651d507d8d9fac77ea17b8bb1a1
Reviewed-on: http://gerrit.cloudera.org:8080/20156
Reviewed-by: Daniel Becker <daniel.becker@cloudera.com>
Tested-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com>
The $IMPALA_HOME/thirdparty directory is a remnant from before
Impala was an Apache project. It is obsolete and unused, so this
removes code that references this directory.
Testing:
- Ran core tests
Change-Id: I2edfd499febb5a25fdcf59b5183eccf192a08be0
Reviewed-on: http://gerrit.cloudera.org:8080/13092
Reviewed-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com>
Tested-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com>
If Impala was built with --build_shared_libs, some thirdparty libraries
were still statically linked; this could cause runtime errors if the
libraries were also linked into a .so. This patch fixes that issue (for
gflags, glog and protobuf at least) by ensuring that build_shared_libs
is respected for those libraries.
* Standardize thirdparty library handling w/CMake by adding
IMPALA_ADD_THIRDPARTY_LIB. This creates a symbolic name for each
library, allowing us to switch the underlying library
files (e.g. change from static to dynamic linking) without having to
individually change the link clauses for each target.
* Remove most cases of add_library() from cmake_modules/* - that is all
handled by IMPALA_ADD_THIRDPARTY_LIB.
* Add shared library detection for a couple of thirdparty
dependencies (many only detect static libraries), just to prove the concept.
* All thirdparty libraries now print a standard set of messages. For example:
-- ----------> Adding thirdparty library protoc. <----------
-- Header files: /data/henry/src/cloudera/impala-toolchain/protobuf-2.6.1/include
-- Added shared library dependency protoc: /data/henry/src/cloudera/impala-toolchain/protobuf-2.6.1/lib/libprotoc.so
-- ----------> Adding thirdparty library libev. <----------
-- Header files: /data/henry/src/cloudera/impala-toolchain/libev-4.20/include
-- Added shared library dependency libev: /data/henry/src/cloudera/impala-toolchain/libev-4.20/lib/libev.so
* Some libraries don't quite fit this pattern (LLVM and Boost) - leave
them as is for now.
* Remove FindOpenSSL.cmake - the toolchain one is more modern.
Change-Id: Ib7a6bc5610aaf2450f91348d94cfb984c6a4b78d
Reviewed-on: http://gerrit.cloudera.org:8080/7418
Tested-by: Impala Public Jenkins
Reviewed-by: Tim Armstrong <tarmstrong@cloudera.com>
This patch makes sure that the Impala-lzo build can pickup the
cmake modules from Impala to avoid code duplication on the lzo side.
Change-Id: I7917946724ce4bfaa281e708e9ea5799b4e2cd37
Reviewed-on: http://gerrit.cloudera.org:8080/552
Reviewed-by: Martin Grund <mgrund@cloudera.com>
Tested-by: Internal Jenkins
This patch allows to optionally enable the new Impala binary
toolchain. For now there are now major version differences in the
toolchain dependencies and what is currently kept in thirdparty.
To enable the toolchain, export the variable IMPALA_TOOLCHAIN to the
folder where the binaries are available.
In addition this patch moves gutil from the thirdparty directory into
the source tree of be/src to allow easy propagation of compiler and
linker flags. Furthermore, the thrift-cpp target was added as a
dependency to all targets that require the generated thrift sources to
be available before the build is started.
What is the new toolchain: The goal of the toolchain is to homogenize
the build environment and to make sure that Impala is build nearly
identical on every platform. To achieve this, we limit the flexibility
of using the systems host libraries and rather rely on a set of custom
produced binaries including the necessary compiler.
Change-Id: If2dac920520e4a18be2a9a75b3184a5bd97a065b
Reviewed-on: http://gerrit.cloudera.org:8080/427
Reviewed-by: Adar Dembo <adar@cloudera.com>
Tested-by: Internal Jenkins
Reviewed-by: Martin Grund <mgrund@cloudera.com>
