hawq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lei Chang <lei_ch...@apache.org>
Subject Re: HAWQ 795,796,797
Date Thu, 23 Jun 2016 05:51:55 GMT
I think it makes sense to make ORC optionally compiled. Otherwise,
dependencies are not friendly for end users.

Cheers
Lei



On Thu, Jun 23, 2016 at 2:03 AM, Roman Shaposhnik <roman@shaposhnik.org>
wrote:

> On Wed, Jun 22, 2016 at 12:16 AM, Guo Gang <paulguo@gmail.com> wrote:
> > This is a good question and concern. One of the solution is to
> auto-switch
> > the "git submodule" command to "git clone"+"git reset --hard" command in
> > the source tarball.  It means we do not ship previous submodule code in
> our
> > source tarball and we do not ask users to download themselves also.
> >
> > A simple design:
> >
> > For source tarball, we provide an extra file (not in git repo) which
> > includes previous submodule info (e.g. github address, destination path
> > commit number), and we modify configure files on github to set a
> > environment variable to auto-determine (e.g. by checking whether it is a
> > git repo or checking whether the extra file exists or not) the
> "submodule"
> > and "clone" cases, and then the environment variable could be used in
> > makefile to determine which way to download the previous submodule
> > workspace.
>
> I actually don't think this will fly with ASF. The source tarball
> releases are required
> to be as self-contained as possible. What I would suggest instead is
> for you to consider
> treating ORC support as an optional dependency. IOW, if the library is
> detected in
> the environment -- you use it. If not -- not.
>
> Bonus point for actually making it pluggable so that orc.so can be
> dynamically
> loaded at runtime (that would probably require changes on the ORC side as
> well
> since it currently doesn't support .so).
>
> Will this work for you?
>
> Thanks,
> Roman.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message