As we don't use tests (by bug 72375) and they are not installed and they are not really useful (AFAIK they're regression tests, with results useful only to the wine devs), maybe we should make use of the new configure option and --disable-tests ?
(In reply to comment #0) > As we don't use tests (by bug 72375) and they are not installed > and they are not really useful (AFAIK they're regression tests, > with results useful only to the wine devs), maybe we should > make use of the new configure option and --disable-tests ? > Do you have any metrics for how much faster it is to build Wine without the tests? It's a non-trivial amount of time to compile Wine on anything but brand-new hardware and there is a new version every 2 weeks, so it'd be nice to save some time every 2 weeks off the compile time.
(In reply to comment #1) > Do you have any metrics for how much faster it is to build Wine without the > tests? On : - Pentium-R-_4_CPU_2.40GHz - ccache version 2.4 [disabled] - MAKEOPTS="-j2" - CFLAGS="-O2 -march=pentium4 -pipe -ggdb" - FEATURES="buildpkg splitdebug" Without --disable-tests : Sat Dec 6 11:45:31 2008 >>> app-emulation/wine-1.1.10 merge time: 46 minutes and 41 seconds. With --disable-tests : Sat Dec 6 12:24:37 2008 >>> app-emulation/wine-1.1.10 merge time: 34 minutes and 14 seconds. [ebuild R ] app-emulation/wine-1.1.10 USE="X alsa cups dbus gecko hal jpeg ncurses opengl oss xml -esd -gnutls -jack -lcms -ldap -nas -samba -scanner"
*** Bug 260725 has been marked as a duplicate of this bug. ***
Created attachment 189608 [details, diff] Ebuild patch to add USE=buildtests I don't know whether it's worth having a USE flag to build the tests (maybe somebody will want to play around with them...) or whether "buildtests" is the best name, but here's a patch for wine-1.1.20 that disables building tests unless USE=buildtests is specified. FWIW, here's another data point: wine-1.1.20 - Athlon64 X2 2.2GHz - MAKEOPTS=-j1 - CFLAGS="-O2 -march=x86-64 -mtune=k8 -pipe" USE=-buildtests: 22m31.989s USE=buildtests: 30m32.470s
Why not using a more standard 'test' USE flag?
Re: USE=test, the USE flag documentation says it's a "workaround to pull in packages needed to run with FEATURES=test", so I don't know if that's appropriate here (besides which, the tests are only built, not run even for FEATURES=test).
I can't agree with the idea of using custom USEflag — basically because AFAICS these tests aren't installed along with wine. And building a thing that would be neither run nor installed, is just a waste of time. So, the only scenario of building these tests supported by us is when these tests are going to be run. Instead of 'use test' we could use something like 'hasq test ${FEATURES}', I think. And after all, if tests are restricted now anyway, we could anyway just add '--disable-tests' temporarily until better solution is chosen.
Ok, I was wrong, we can't lookup ${FEATURES}. But 'use test' is acceptable and there are many ebuilds in the tree which do that. I'll try to patch the build system to get these tests built on 'make check'.
Created attachment 202270 [details, diff] Compile tests on 'make check' This patch first removes the whole '--disable-tests' code from configure and then modifies Maketest.rules.in to build tests when 'make check' is run. This would be the best solution. Could anyone submit it upstream?
Created attachment 202384 [details, diff] force-configure-to-disable-tests-gentoo-bug-248103.patch Another easy hack for gentoo users to disable tests. Since bug #282735 has been closed, we can now : - mkdir -p /etc/portage/patches/app-emulation/wine - save the attached patch in this directory On Core(TM)2 CPU E7400 @ 2.80GHz : - wine-1.1.28 merge time: 20 minutes and 11 seconds when building tests. - wine-1.1.28 merge time: 15 minutes and 23 seconds with this patch applied.
assuming the configure flag does what it says, Andrew's patch is (almost) fine http://sources.gentoo.org/app-emulation/wine/wine-9999.ebuild?r1=1.40&r2=1.41 http://sources.gentoo.org/app-emulation/wine/wine-1.1.28.ebuild?r1=1.2&r2=1.3
