From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: shortening the git test suite Date: Sun, 08 Jul 2018 18:41:23 -0400 Message-ID: <87lgale4fg.fsf@netris.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46576) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fcIOL-0005CX-7J for guix-devel@gnu.org; Sun, 08 Jul 2018 18:42:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fcIOI-000357-4a for guix-devel@gnu.org; Sun, 08 Jul 2018 18:42:53 -0400 In-Reply-To: <87y3emsp57.fsf@elephly.net> (Ricardo Wurmus's message of "Sat, 07 Jul 2018 23:37:56 +0200") 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: Ricardo Wurmus Cc: guix-devel@gnu.org Hi Ricardo, Ricardo Wurmus writes: > Mark H Weaver writes: > >>>> Also, looking ahead, I think it would be great if we could eventually >>>> move to a model where the tests of some packages are split off into >>>> separate derivations. Similarly, we could work toward splitting off >>>> documentation generation to separate derivation for selected packages. >>>> The most important advantage to this approach is that it would allow >>>> inputs needed only for tests or docs to be omitted from the inputs of >>>> the main package. I expect that this will in many cases be needed to >>>> prevent circular dependencies, and it could also greatly reduce the >>>> amount of rebuilding needed after updating certain packages. >>> >>> Currently if test fails, the whole derivation fails, and you can=E2=80= =99t >>> install your package. If tests were run separately, this would no >>> longer hold: you could get your package regardless of whether tests >>> fail. >> >> Indeed, and I agree that we would need to address this. >> >>> How would you address this? I guess that calls for a new build >>> model, no? >> >> 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. Mark