From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: shortening the git test suite Date: Mon, 09 Jul 2018 09:47:53 +0200 Message-ID: <87o9fgsvdi.fsf@elephly.net> References: <87r2ko6pby.fsf@elephly.net> <87r2ki2hso.fsf@gmail.com> <87fu0y11ir.fsf@elephly.net> <87sh4wgrc3.fsf@netris.org> <87va9s9itb.fsf@gnu.org> <87a7r3gfmx.fsf@netris.org> <87y3emsp57.fsf@elephly.net> <87lgale4fg.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45783) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fcQuF-0008S8-10 for guix-devel@gnu.org; Mon, 09 Jul 2018 03:48:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fcQuE-0004A3-6b for guix-devel@gnu.org; Mon, 09 Jul 2018 03:48:23 -0400 In-reply-to: <87lgale4fg.fsf@netris.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Mark H Weaver Cc: guix-devel@gnu.org Hi Mark, >>> I'm not sure what you mean by "build model", whether you are talking >>> about the daemon interface or something else, but I think the changes >>> could be confined to the Guix user interface. A field could be added to >>> , somewhat similar to 'replacement', but pointing to a package >>> object which runs tests, or perhaps a list of package objects. The guix >>> client could simply add the test packages to the list of derivations to >>> build. This could be inhibited via a "--no-tests" guix build option. >> >> A problem that would need solving is that tests often depend on the >> build directory, which is different from what is installed (and ends up >> in the store). The build directory is lost. > > I suggested a solution to this problem in my paragraph immediately > following the one you quoted above. Did you see it? Here it is again: > > In typical cases where "make check" expects to be run from a fully built > source directory, the main package would typically produce a tarball of > the built source directory as an additional output. The test package > would simply unpack this tarball and run "make check" in it. Yes, I read it, but I misunderstood your suggestion regarding the tarball. This build directory output which would be used to continue the build would likely not be reproducible as it contains files that are not meant to be installed, such as logs with timestamps. Is this okay? -- Ricardo