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 <[email protected]> wrote: > On Wed, Jun 22, 2016 at 12:16 AM, Guo Gang <[email protected]> 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. >
