Re: Build system discussion for Arrow (and Orc?)
How did you hit the -Werror issue? I'm looking at your patch
but this should not be impacting you. The default warning level is
PRODUCTION, -Werror is only being added for CHECKIN and EVERYTHING
warning levels (which we use in CI)
On Fri, Jun 22, 2018 at 10:15 AM, Michael Sarahan <msarahan@xxxxxxxxx> wrote:
> Thanks for the reminder. I only very recently was able to finish up my work
> on our arrow package.
> 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 <wesmckinn@xxxxxxxxx> 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.
>> On Tue, Apr 24, 2018 at 10:54 AM, Wes McKinney <wesmckinn@xxxxxxxxx>
>> > +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 <uwelk@xxxxxxxxxx> 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
>> >>> 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