[
https://issues.apache.org/jira/browse/PARQUET-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15745803#comment-15745803
]
William Forson commented on PARQUET-798:
----------------------------------------
Thanks for the response!
It's a shame I didn't post my original issue to the correct page, as I spent
some time playing around with this last month but have forgotten everything by
now.
Anyway, I'm attaching the cmake output with {{THRIFT_HOME}} set, but without
any other tweaks, as cmake_output_original.txt. At this point, the
thrift-finding cmake logic picks up my system libraries rather than the ones
under {{$THRIFT_HOME/lib}}. (IIRC it was reasonably easy to get around this by
tweaking the cmake logic, btw) For reference:
{block}
$ ls -R thrift_home/
thrift_home/:
bin include lib
thrift_home/bin:
thrift
thrift_home/include:
thrift
thrift_home/include/thrift:
async cxxfunctional.h qt TDispatchProcessor.h
TLogging.h transport
concurrency processor server thrift-config.h
TOutput.h TToString.h
config.h protocol TApplicationException.h Thrift.h
TProcessor.h
thrift_home/include/thrift/async:
TAsyncBufferProcessor.h TAsyncDispatchProcessor.h TAsyncProtocolProcessor.h
TEvhttpClientChannel.h
TAsyncChannel.h TAsyncProcessor.h TConcurrentClientSyncInfo.h
TEvhttpServer.h
thrift_home/include/thrift/concurrency:
BoostThreadFactory.h Monitor.h PosixThreadFactory.h
StdThreadFactory.cpp ThreadManager.h
Exception.h Mutex.h StdMonitor.cpp
StdThreadFactory.h TimerManager.h
FunctionRunner.h PlatformThreadFactory.h StdMutex.cpp Thread.h
Util.h
thrift_home/include/thrift/processor:
PeekProcessor.h StatsProcessor.h TMultiplexedProcessor.h
thrift_home/include/thrift/protocol:
TBase64Utils.h TCompactProtocol.h TJSONProtocol.h
TProtocolException.h TVirtualProtocol.h
TBinaryProtocol.h TCompactProtocol.tcc TMultiplexedProtocol.h TProtocol.h
TBinaryProtocol.tcc TDebugProtocol.h TProtocolDecorator.h
TProtocolTap.h
thrift_home/include/thrift/qt:
TQIODeviceTransport.h TQTcpServer.h
thrift_home/include/thrift/server:
TConnectedClient.h TServerFramework.h TSimpleServer.h TThreadPoolServer.h
TNonblockingServer.h TServer.h TThreadedServer.h
thrift_home/include/thrift/transport:
PlatformSocket.h THttpServer.h TServerTransport.h
TSSLServerSocket.h TVirtualTransport.h
TBufferTransports.h THttpTransport.h TShortReadTransport.h TSSLSocket.h
TZlibTransport.h
TFDTransport.h TPipe.h TSimpleFileTransport.h
TTransportException.h
TFileTransport.h TPipeServer.h TSocket.h TTransport.h
THttpClient.h TServerSocket.h TSocketPool.h TTransportUtils.h
thrift_home/lib:
libthrift-0.9.3.so libthrift.la libthriftqt.a libthriftqt.so
libthriftz-0.9.3.so libthriftz.la
libthrift.a libthriftqt-0.9.3.so libthriftqt.la libthrift.so
libthriftz.a libthriftz.so
{block}
> usage of THRIFT_HOME in build?
> ------------------------------
>
> Key: PARQUET-798
> URL: https://issues.apache.org/jira/browse/PARQUET-798
> Project: Parquet
> Issue Type: Bug
> Components: parquet-cpp
> Reporter: William Forson
>
> Hi,
> I posted this issue a while back on the old parquet-cpp github page and
> forgot about it...until just now.
> First of all, to briefly describe my use case: I am using parquet-cpp as a
> dependency in a project which already has a dependency on thrift. As such,
> I'd like to be able to build parquet-cpp against the version of thrift which
> we are already using in the project.
> When I first spotted the notes regarding {{THRIFT_HOME}} in the readme, I
> thought this looked like exactly what I wanted -- that is, a way to configure
> the parquet-cpp build process to use external/pre-built thrift artifacts. So,
> for starters: am I simply misinterpreting the meaning of {{THRIFT_HOME}}?
> (e.g. does that specify a _destination_ directory for thrift artifacts built
> during the parquet-cpp 3p build step?) And if so, is there any good way (or
> bad way) to accomplish what I'm trying to do here?
> Otherwise, when I try to use my own thrift installation (via
> {{THRIFT_HOME}}), the build fails like so:
> {quote}
> $ make parquetcpp
> cd parquet-cpp && source ./thirdparty/set_thirdparty_env.sh && make
> make[1]: Entering directory `parquet-cpp'
> make[2]: Entering directory `parquet-cpp'
> make[3]: Entering directory `parquet-cpp'
> Scanning dependencies of target parquet_thrift
> make[3]: Leaving directory `parquet-cpp'
> make[3]: Entering directory `parquet-cpp'
> [ 1%] Building CXX object
> src/parquet/thrift/CMakeFiles/parquet_thrift.dir/parquet_types.cpp.o
> parquet-cpp/src/parquet/thrift/parquet_types.cpp: In member function
> ‘uint32_t
> parquet::format::Statistics::read(apache::thrift::protocol::TProtocol*)’:
> parquet-cpp/src/parquet/thrift/parquet_types.cpp:179:3: error:
> ‘TInputRecursionTracker’ is not a member of ‘apache::thrift::protocol’
> apache::thrift::protocol::TInputRecursionTracker tracker(*iprot);
> ^
> parquet-cpp/src/parquet/thrift/parquet_types.cpp: In member function
> ‘uint32_t
> parquet::format::Statistics::write(apache::thrift::protocol::TProtocol*)
> const’:
> parquet-cpp/src/parquet/thrift/parquet_types.cpp:244:3: error:
> ‘TOutputRecursionTracker’ is not a member of ‘apache::thrift::protocol’
> apache::thrift::protocol::TOutputRecursionTracker tracker(*oprot);
> ^
> parquet-cpp/src/parquet/thrift/parquet_types.cpp: In member function
> ‘uint32_t
> parquet::format::SchemaElement::read(apache::thrift::protocol::TProtocol*)’:
> parquet-cpp/src/parquet/thrift/parquet_types.cpp:357:3: error:
> ‘TInputRecursionTracker’ is not a member of ‘apache::thrift::protocol’
> apache::thrift::protocol::TInputRecursionTracker tracker(*iprot);
> ^
> parquet-cpp/src/parquet/thrift/parquet_types.cpp: In member function
> ‘uint32_t
> parquet::format::SchemaElement::write(apache::thrift::protocol::TProtocol*)
> const’:
> parquet-cpp/src/parquet/thrift/parquet_types.cpp:471:3: error:
> ‘TOutputRecursionTracker’ is not a member of ‘apache::thrift::protocol’
> apache::thrift::protocol::TOutputRecursionTracker tracker(*oprot);
> ^
> <SNIP ... you get the idea>
> ^
> parquet-cpp/src/parquet/thrift/parquet_types.cpp: In member function
> ‘uint32_t
> parquet::format::FileMetaData::read(apache::thrift::protocol::TProtocol*)’:
> parquet-cpp/src/parquet/thrift/parquet_types.cpp:2646:3: error:
> ‘TInputRecursionTracker’ is not a member of ‘apache::thrift::protocol’
> apache::thrift::protocol::TInputRecursionTracker tracker(*iprot);
> ^
> parquet-cpp/src/parquet/thrift/parquet_types.cpp: In member function
> ‘uint32_t
> parquet::format::FileMetaData::write(apache::thrift::protocol::TProtocol*)
> const’:
> parquet-cpp/src/parquet/thrift/parquet_types.cpp:2775:3: error:
> ‘TOutputRecursionTracker’ is not a member of ‘apache::thrift::protocol’
> apache::thrift::protocol::TOutputRecursionTracker tracker(*oprot);
> ^
> make[3]: ***
> [src/parquet/thrift/CMakeFiles/parquet_thrift.dir/parquet_types.cpp.o] Error 1
> make[3]: Leaving directory `parquet-cpp'
> make[2]: *** [src/parquet/thrift/CMakeFiles/parquet_thrift.dir/all] Error 2
> make[2]: Leaving directory `parquet-cpp'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `parquet-cpp'
> make: *** [<...>/libparquet.a] Error 2
> {quote}
> This kinda smells like a circular dependency (as all of the types/headers
> mentioned above look fine), but I haven't dug through the internals of the
> parquet-cpp build logic enough to diagnose it in more detail. Before doing
> so, I wanted to post here for a sanity check on my use case, and the intended
> semantics/usage of {{THRIFT_HOME}}.
> Any help/clarification will be much appreciated!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
