On Wed, Jul 18, 2018 at 12:42 PM Todd Lipcon <t...@cloudera.com.invalid> wrote:
> On Wed, Jul 18, 2018 at 12:38 PM, Mike Percy <mpe...@apache.org> wrote: > > > So I was able to get a proof-of-concept working [1], although the script > is > > a bit hacky. The hacky part is that I arbitrarily chose a few system > > modules not to package until the thing was willing to run. I was able to > > build Kudu on EL6 and run it on Ubuntu 16.04. I have not make it work on > > macOS yet... the commands for the rpath modifications to make it > > relocatable would be different but the effect should be similar: library > > paths relative to the binary. > > > > To get this proof-of-concept to a usable state, we still would need the > > following pieces: > > > > 1) Make the above script also work on macOS using install_name_tool > > and @loader_path per [2] > > > > I wonder whether for OSX it would be easier to just assume Docker? We > already know we have various functional limitations on OSX, so maybe it > would simplify our release process if we didn't have to worry about > creating this special artifact on OSX? I would guess that most OSX > developers either already have or would be willing to install Docker. > If we require Docker on Mac to run, then it probably doesn't make sense to enable Kudu tests by default on Mac on downstream projects such as Beam, Flink, Flume, Spark, etc. I suspect the Kudu tests would usually be skipped. Mike