> I'm pretty busy this week and would be happy to get some help on this if anybody has cycles to spare.
Thanks Mike - I'll look into 3) and if we get it working I'm happy to offer a PR for 4). This is an evening project for me so I might be a little slow too - if someone else is keen and has time please feel free to jump in. On Wed, Jul 18, 2018 at 10:16 PM, Mike Percy <[email protected]> wrote: > On Wed, Jul 18, 2018 at 12:42 PM Todd Lipcon <[email protected]> > wrote: > > > On Wed, Jul 18, 2018 at 12:38 PM, Mike Percy <[email protected]> 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 >
