Add option for external C++ development toolchain, use C++11, configure libparquet library / header installation

[wesm]

This PR makes no functional changes to the codebase, but is more a reorganization for using parquet-cpp as a building block for other native code projects. After this I'm going to start working on functional unit tests and working toward a complete reader / writer implementation.

Notably this patch removes the thirdparty packages and will rely either on cloudera/native-toolchain for development / linking or system-level dynamic libraries. You can also perform out-of-source builds.

I have not tried getting Travis CI to work with the native toolchain; I may enlist the help of @grundprinzip on this portion.

[wesm]

Can someone let me know what are the appropriate copyright headers to use in these files? In copy-pasting from other Apache / Apache-licensed Cloudera C++ projects like Impala and Kudu I've transferred a few Cloudera copyright headers

[spena]

@wesm I think the license header should contain only the Apache license information. You may want to remove the Cloudera copyright as Parquet is now part of the Apache community. A header like this may be pasted on those cpp or cmake files:

/**

• Licensed to the Apache Software Foundation (ASF) under one
• or more contributor license agreements. See the NOTICE file
• distributed with this work for additional information
• regarding copyright ownership. The ASF licenses this file
• to you under the Apache License, Version 2.0 (the
• "License"); you may not use this file except in compliance
• with the License. You may obtain a copy of the License at
  *
• http://www.apache.org/licenses/LICENSE-2.0

• Unless required by applicable law or agreed to in writing,
• software distributed under the License is distributed on an
• "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
• KIND, either express or implied. See the License for the
• specific language governing permissions and limitations
• under the License.
  */

[wesm]

Thanks -- since this codebase never got "shipped" in the past this has not been an issue. I can fix the copyright headers in a follow up patch so avoid adding any more noise to this patch if that is OK.

[asandryh]

Hi Wes,
Can you please clarify the motivation for this code reorganization? I haven't had problems building parquet-cpp against system-installed or manually built libraries. With your changes, the build fails. Note that your pull request removes /thirdparty directory, so you certainly should update build instructions.
Overall, it is not necessary at all that building parquet-cpp should rely on cloudera/native-toolchain. This is a stand-alone library, and linking in external libraries should be performed via user-specified CMake options.
Thank you.

[wesm]

@asandryh I completely agree — per #10 and PARQUET-267 I am going to ensure that building with system-installed libraries or indicating 3rd party dependencies via cmake options is the default and simplest option. The motivation in adding an external toolchain option was to facilitate development and linking with other C++ libraries sharing a common portable Linux toolchain.

[asandryh]

@wesm Thank you for the clarification. It looks like @kalaxy in #10 has exactly the same concerns as I.
Your proposed refactoring is very reasonable. My main concern with this pull request is that, with your current modifications to CMake config, the library does not build with user-specified libraries.

[nongli]

@wesm can you split this patch in two? I think the one that rearranges the source structure, headers, #define cleanups etc are not controversial and can go in. The build step needs more discussion.

[nongli]

@wesm can you participate in the discussion here
https://issues.apache.org/jira/browse/PARQUET-267

[wesm]

@nongli no problem, I'll spend some time this afternoon and open a new build environment patch per discussion in PARQUET-267.

[wesm]

Closing in favor of #14 and follow up patch re: more flexible build environment configuration.