02/08/2019 22:59, Aaron Conole: > Thomas Monjalon <tho...@monjalon.net> writes: > > 31/07/2019 22:54, Michael Santana Francisco: > >> On Wed, Jul 31, 2019 at 10:50 AM Aaron Conole <acon...@redhat.com> wrote: > >> > --- a/.ci/linux-build.sh > >> > +++ b/.ci/linux-build.sh > >> > @@ -22,3 +22,11 @@ fi > >> > OPTS="$OPTS --default-library=$DEF_LIB" > >> > meson build --werror -Dexamples=all $OPTS > >> > ninja -C build > >> > + > >> > +if [ "$RUN_TESTS" = "1" ]; then > >> > + # On the test build, also build the documentation, since it's > >> > expensive > >> > + # and we shouldn't need to build so much of it. > >> > + ninja -C build doc > > > > I am not sure to understand the comment. > > Do you mean you build the documentation only once, > > which is when running tests? > > Yes. > > > Why it is not a new option similar as RUN_TESTS? > > I mentioned it at: > http://mails.dpdk.org/archives/dev/2019-July/136635.html also. Because > it adds build time.
I don't understand. If you set RUN_TESTS and BUILD_DOCS on the same build, how is it adding build time? I'm just suggesting to make explicit that tests and docs are done in the same run. > >> > --- a/.travis.yml > >> > +++ b/.travis.yml > >> > @@ -30,6 +30,7 @@ env: > >> > - DEF_LIB="shared" > >> > - DEF_LIB="static" OPTS="-Denable_kmods=false" > >> > - DEF_LIB="shared" OPTS="-Denable_kmods=false" > >> > + - DEF_LIB="shared" RUN_TESTS=1 > >> I don't agree with this. This is redundant. Why not put RUN_TESTS=1 on > >> an already exiting builds instead of adding two new builds like you > >> are doing here? > > > > I agree it is a strange logic. > > Why not use an existing build to run the tests? > > The biggest reason is when it fails, it is difficult to know why "at a > glance." When it does fail due to unit tests, it sometimes takes a > long time to load the logs - so just knowing that the failure is likely > in the unit tests area vs. build is helpful to understand where to start > looking. > > It isn't a big deal to merge them, though if you'd prefer it. It looks to be a good reason. I'm just sad that we cannot reuse an existing build in another way. But I guess the infrastructure cache (ccache or other) will be enough.
