On Fri, 2020-03-20 at 17:27 +0000, Daniel P. Berrangé wrote: > On Fri, Mar 20, 2020 at 06:07:47PM +0100, Andrea Bolognani wrote: > > * why do we care about whether all those features are enabled or > > not? It's pretty ugly to have that list hardcoded in our build > > scripts, and I don't quite get the point in having it in the > > first place; > > It is to reduce the build time - it cuts time for the job in 1/2 > which is worthwhile win. On my laptop, where make is configured to use parallel builds by default through $MAKEFLAGS: $ git clean -xdf && time sh -c 'mkdir build && cd build && ../autogen.sh && make && make install DESTDIR=$(pwd)/../install' real 2m52.997s user 14m46.604s sys 1m56.444s $ git clean -xdf && time sh -c 'mkdir build && cd build && ../autogen.sh --without-libvirtd --without-esx --without-hyperv --without-test --without-dtrace --without-openvz --without-vmware --without-attr --without-audit --without-blkid --without-bash-completion --without-capng --without-curl --without-dbus --without-firewalld --without-fuse --without-glusterfs --without-libiscsi --without-libssh --without-numactl --without-openwsman --without-pciaccess --without-readline --without-sanlock --without-sasl --without-selinux --without-ssh2 --without-udev && make && make install DESTDIR=$(pwd)/../install' real 1m59.594s user 9m4.929s sys 1m13.152s $ git clean -xdf && time sh -c 'mkdir build && cd build && ../autogen.sh && make -C docs/ && make -C docs/ install DESTDIR=$(pwd)/../install' real 0m33.350s user 0m54.281s sys 0m10.986s So we can basically have our cake and eat it too! :) > Using gitlab stages for different types of builds gives us a more > friendly output view. We can distinguish what aspect of the build > has failed at a glance instead of having to peer into the 100's > of KB of build logs. Are we eventually going to have the same syntax-check / build / check split as we currently have in Jenkins? > Eventually we can make use of filters so that when people submit > a patch which only touches the docs, we can skip all the native > build and cross build jobs entirely, only running the docs stage. Sounds like a nice little optimization, assuming we can get it to work reliably, but I have to wonder how frequent it really is that the documentation is updated outside of a series that touches the code as well... -- Andrea Bolognani / Red Hat / Virtualization
