Skip to content
This repository was archived by the owner on May 10, 2024. It is now read-only.

Conversation

@kalaxy
Copy link
Contributor

@kalaxy kalaxy commented Apr 29, 2015

Apache Jira Link: https://issues.apache.org/jira/browse/PARQUET-267

This pull request builds on top of #9.

@kalaxy kalaxy force-pushed the move_thirdparty_to_build_env branch from 56f1a03 to 4812794 Compare April 29, 2015 17:51
@nongli
Copy link
Contributor

nongli commented May 7, 2015

Can you update the README with some steps on how to get these dependencies you removed? Perhaps just pointing them to the travis config file.

It would be nice to have as few steps as possible between cloning the repo and running the code.

@kalaxy kalaxy force-pushed the move_thirdparty_to_build_env branch 2 times, most recently from 624f768 to 5fa9122 Compare May 7, 2015 15:07
@kalaxy
Copy link
Contributor Author

kalaxy commented May 7, 2015

Sure thing. I added a few lines indicating how to set up a build env and pointed to the .travis.yml as well. I also rebased the pull request off of the current master. Let me know what you think.

@kalaxy kalaxy force-pushed the move_thirdparty_to_build_env branch from 5fa9122 to fc08d67 Compare May 7, 2015 15:11
@wesm
Copy link
Member

wesm commented Dec 24, 2015

@kalaxy this is potentially subsumed by #13; I don't have Travis working yet, perhaps we can collaborate.

@kalaxy
Copy link
Contributor Author

kalaxy commented Jan 4, 2016

@wesm, I checked out your branch and tried compiling. I didn't get far. It seems that native toolchain, I'm not sure what that is, is sort of a requirement with your cmake setup. Setting DISABLE_NATIVE_TOOLCHAIN still doesn't allow various libraries to be found properly. However, we might be able to come up with a merge between our branches that supports both of our use cases.

@kalaxy
Copy link
Contributor Author

kalaxy commented Jan 4, 2016

@wesm, A couple more thoughts. It looks like cmake_modules/toolchain.cmake is setting up a build environment. This is a bit contrary to what I was trying to accomplish here. My personal philosophy is that the build environment should not be in committed code. I think build config should be sufficiently parameterized to allow any build maintainer or developer flexibility to override library locations and versions as desired while defaulting to system locations and versions. That was my goal with this pull request, to permit build environment configurability.

That said, I think that your code refactorings are great additions and would love to pull them on top of this build config.

@wesm
Copy link
Member

wesm commented Jan 4, 2016

@kalaxy the idea is adding an optional portable (across Linux distributions) build environment. I didn't intend to make it the only option, so I will need to fix the build presuming that the user has installed the appropriate system libraries. I think merging our efforts should not be too difficult.

The end goal here is to make adding more 3rd party dependencies easier as well as building and linking libparquet with other projects sharing a common library toolchain.

@kalaxy
Copy link
Contributor Author

kalaxy commented Jan 8, 2016

Superseded by #16.

@kalaxy kalaxy closed this Jan 8, 2016
@kalaxy kalaxy deleted the move_thirdparty_to_build_env branch January 20, 2016 17:05
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants