Unfortunately some of the benchmarks have actually bit-rotted. For example, expr-benchmark compiles but immediately throws JNI exceptions.
On Tue, Feb 21, 2017 at 10:55 AM, Marcel Kornacker <mar...@cloudera.com> wrote: > I'm also in favor of not compiling it on the standard commandline. > > However, I'm very much against allowing the benchmarks to bitrot. As > was pointed out, those benchmarks can be valuable tools during > development, and keeping them in working order shouldn't really impact > the development process. > > In other words, let's compile them as part of gvo. > > On Tue, Feb 21, 2017 at 10:50 AM, Alex Behm <alex.b...@cloudera.com> > wrote: > > +1 for not compiling the benchmarks in -notests > > > > On Mon, Feb 20, 2017 at 7:55 PM, Jim Apple <jbap...@cloudera.com> wrote: > > > >> > On which note, would anyone object if we disabled benchmark > compilation > >> by > >> > default when building the BE tests? I mean separating out -notests > into > >> > -notests and -build_benchmarks (the latter false by default). > >> > >> I think this is a great idea. > >> > >> > I don't mind if the benchmarks bitrot as a result, because we don't > run > >> > them regularly or pay attention to their output except when > developing a > >> > feature. Of course, maybe an 'exhaustive' run should build the > benchmarks > >> > as well just to keep us honest, but I'd be happy if 95% of Jenkins > builds > >> > didn't bother. > >> > >> The pre-merge (aka GVM aka GVO) testing builds > >> http://jenkins.impala.io:8080/job/all-build-options, which builds > >> without the "-notests" flag. > >> >