Thanks for the reminder. I only very recently was able to finish up my work on our arrow package.
https://github.com/AnacondaRecipes/arrow-cpp-feedstock/tree/master/recipe There are some bugs in the patches I've just noticed - ORC_VENDORED isn't set properly, copy paste error. I'd also like to put the -werror behind some kind of flag so that either we can disable it, or you can enable it. I'm open to your opinions on what the default behavior should be. IMHO, disabled is better as a default, but you should enable it for your local builds and for CI. I am traveling today, but will try to put up a PR sometime this afternoon. On Fri, Jun 22, 2018, 04:22 Wes McKinney <wesmck...@gmail.com> wrote: > hi Michael, > > I wanted to rekindle this discussion so that we can resolve these > issues before Arrow 0.10.0 is released. Can you let us know what needs > to be changed or submit a PR? I have a PR coming in for ARROW-902 > shortly (offline builds), and I think it would be a good idea to > enable all third party dependencies to use dynamic linking if the user > so desired. > > Thanks, > Wes > > On Tue, Apr 24, 2018 at 10:54 AM, Wes McKinney <wesmck...@gmail.com> > wrote: > > +1. Definitely do open JIRAs to describe the issue(s) you are having, > > even if you do not intend to patch them yourself. The ORC issue may > > need to be patched upstream in Apache ORC. We're happy to help spec > > out the work required to help make the builds / packaging less painful > > > > Thanks > > Wes > > > > On Wed, Apr 11, 2018 at 5:39 AM, Uwe L. Korn <uw...@xhochy.com> wrote: > >> Hello Michael, > >> > >>> 1. Is this a welcome change, or should we just carry patches locally? > >> > >> These changes would be very welcome. The current vendoring approach > exists for all dependencies mostly to get have a smooth development > experience. It is not meant for releases. The current approach for ORC is > mainly in this form as there are things missing to get to a smooth, > non-vendored released binary. > >> > >>> 2. Assuming change is welcome, what is the preferred method for > submitting > >>> changes? Github PR(s)? > >> > >> As mentioned above, they are very welcome. The preferred method is > creating an issue in JIRA https://issues.apache.org/jira/projects/ARROW > and then opening a PR on github. The name of the PR should be prefixed with > the issue. e.g. `ARROW-XXX: [Python] Better ORC packaging` > >> > >> Uwe >
