From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41077) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tw7gr-0002zf-7E for qemu-devel@nongnu.org; Fri, 18 Jan 2013 03:52:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tw7gq-0000hW-8S for qemu-devel@nongnu.org; Fri, 18 Jan 2013 03:52:45 -0500 Received: from mail-ee0-f44.google.com ([74.125.83.44]:55426) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tw7gq-0000hR-23 for qemu-devel@nongnu.org; Fri, 18 Jan 2013 03:52:44 -0500 Received: by mail-ee0-f44.google.com with SMTP id l10so1674095eei.3 for ; Fri, 18 Jan 2013 00:52:43 -0800 (PST) Sender: Paolo Bonzini Message-ID: <50F90D57.3050806@redhat.com> Date: Fri, 18 Jan 2013 09:52:39 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1358239777-29911-1-git-send-email-pbonzini@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] tests: adjust gcov variables for directory movement List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel@nongnu.org Il 17/01/2013 21:43, Blue Swirl ha scritto: >> > Blue, can you look at introducing a common variable for the coroutine >> > backend? Like >> > >> > coroutine-backend-y = gthread >> > coroutine-backend-$(CONFIG_SIGALTSTACK_COROUTINE) = sigaltstack >> > coroutine-backend-$(CONFIG_UCONTEXT_COROUTINE) = ucontext >> > coroutine-backend-$(CONFIG_WIN32) = win32 >> > >> > and using it in both Makefile.objs and tests/Makefile. >> > Another alternative is to use $(filter) to pick the one file that >> > is actually part of $(block-obj-y). Thanks! > OK. Related to this, perhaps it would be better to rearrange the test > directory so that in most cases there is 1:1 relation with a test and > the code that it tests, for example qobject/qdict.c would be tested by > tests/qobject/qdict.c. This would simplify the Makefile a lot. I'd prefer tests/qobject/check-qdict.c, but that's the idea yes. > Then we could also add a dummy test for each source file mechanically > to see how low the test coverage really is and to encourage writing > more of them. True, one of the points of introducing libqemuutil.a is to easily identify code that can be unit tested and headers where gtk-doc comments can be added. Of course there can be other unit tests (e.g. main loop, coroutines, QOM, etc.) but that's the low-hanging fruit. Paolo