From owner-freebsd-testing@FreeBSD.ORG Sun Oct 27 22:12:41 2013 Return-Path: Delivered-To: freebsd-testing@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 53C304D6 for ; Sun, 27 Oct 2013 22:12:41 +0000 (UTC) (envelope-from julio@meroh.net) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D6F1020E8 for ; Sun, 27 Oct 2013 22:12:40 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id el20so4640669lab.14 for ; Sun, 27 Oct 2013 15:12:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=J7yxRdNxA3iSB0+XcSFrpujV7vXzFp1uQIuszaE6ayQ=; b=Jx9jUovTnZCx0ousw2D1ZyiiAJEU27dw3jjm1FP9zxJBvM3sg9xb+gRS46ukVKpAZB 14NGqYK996scgMvIyRVWgG2m/sf3GtCawq2GSUG/5uK1SOY1sOmi9ru0weOXNLa0DF5j 0dIWptjpEo8oBl0RaGawhzNdE8P4PZgb3hvkjeECmUETvSesOohz3ZHz0xfkaFwaHSeg s/hcmrNQb7lfHri4TZbamlSMyRfDrC9WZqeCzyZkhqDqoQjVvQ9xFBVTwBw1AoGZeMlB iog33aTV6wOWFYfrMBJU5z0ImmSSPRnExZS7pul5fMt1XaJFmuJlj3+cxFKrikRjqgeT domQ== X-Gm-Message-State: ALoCoQnq3EaPo9zxUnPmTm8DC508hiljGLdbCh1ypNoaUdukzbaMVLK8Aj1+Z1onaeZw/7yykAJy X-Received: by 10.152.121.3 with SMTP id lg3mr12452264lab.0.1382911952730; Sun, 27 Oct 2013 15:12:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.132.135 with HTTP; Sun, 27 Oct 2013 15:12:12 -0700 (PDT) X-Originating-IP: [108.176.158.82] From: Julio Merino Date: Sun, 27 Oct 2013 18:12:12 -0400 Message-ID: Subject: Plugging ATF tests into the build and other cleanups To: freebsd-testing@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Rui Paulo , Simon Gerraty X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 22:12:41 -0000 Hello! The next patch set is up for review. In this case, the goal is to plug the ATF tests into the build. Please note that the patches are ready for review but not ready for submission. The built tests raise several errors and I still need to diagnose if these are because of problems in my reachover Makefiles or if they are just broken under my machine (powerpc64). That said, fixing these should not affect the structure of the patches much, so please go ahead and take a look! While doing this, I have discovered a few minor issues that need addressing and some improvements to be made, so I have tossed them into the patches. The one concern I have here is having to keep track of all tests in tools/build/mk/OptionalObsoleteFiles.inc so that setting WITHOUT_TESTS=no cleans up /usr/tests. This will be a pain to maintain and a sure source of inconsistencies. If we could special-case this to make it more automatic, do you have any suggestions? As usual: http://portal.meroh.net/~jmmv/freebsd-testing/ Thanks! -- Julio Merino / @jmmv From owner-freebsd-testing@FreeBSD.ORG Mon Oct 28 00:26:06 2013 Return-Path: Delivered-To: freebsd-testing@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 26D79333 for ; Mon, 28 Oct 2013 00:26:06 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D98032684 for ; Mon, 28 Oct 2013 00:26:05 +0000 (UTC) Received: by mail-qe0-f47.google.com with SMTP id b4so3589004qen.20 for ; Sun, 27 Oct 2013 17:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0C6j6YA5tD+9zyxWeFUDkBIqNb+bQPs4xw6TAxuyfZ0=; b=NsP/HhwnHu1HtaPuBN4yu3h0SPNvRXZii7/Y/YEWSvONj35AFuNRKfSoL473SPPdWK HmsCWb5pW3/Qxp7i09RJriw9nJCkqfcWwF9LqwondwWRSR1cAJdwBtlcaBXbsGH8pyjO EnVDNcsEk0Q35lElGK2WVD+zOHe0Q6DtBHUsI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0C6j6YA5tD+9zyxWeFUDkBIqNb+bQPs4xw6TAxuyfZ0=; b=OsU5CLWlfq/T6vvf6xQnq6a14v9EALs94hB6zI0YtOLtRl0/tC+lTrmRzXj85vi65o peOT8uMA2J/i697bYLDmAuWsiEVbjmQ3VgYWywUzjjUa8RjwQ0AGivX0RfjKygwJfB2H 9YUZKPHibCq9wpxz2idGY7JYvXlxkEgINqeK7DJaA+CWzsdNlGH6q7Yg29GkeFMaTfxl yS/a59VzheeYfrDjErqM8A+zstkI25e4UFZCOsgoqSKvgJO9rf43BArWplAFuoXG4g0y nXWYl76iI4gld9ncG1Z7Oo3wOvdM4kauNwNz1iGGDtx1WsN0AfaHCBy7zuJaNyU3sH8j 0eLA== X-Gm-Message-State: ALoCoQniCidY8fs/I9UIqWeC8qnlg8mF26R1uP6X6xyd6EFBpTealsUomCJfJ7yot3+8nhhxWyur X-Received: by 10.224.34.71 with SMTP id k7mr25517402qad.15.1382919964944; Sun, 27 Oct 2013 17:26:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.63.101 with HTTP; Sun, 27 Oct 2013 17:25:34 -0700 (PDT) In-Reply-To: References: From: Eitan Adler Date: Sun, 27 Oct 2013 20:25:34 -0400 Message-ID: Subject: Re: Plugging ATF tests into the build and other cleanups To: Julio Merino Content-Type: text/plain; charset=UTF-8 Cc: freebsd-testing@freebsd.org, Rui Paulo , Simon Gerraty X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 00:26:06 -0000 On Sun, Oct 27, 2013 at 6:12 PM, Julio Merino wrote: > Hello! > The one concern I have here is having to keep track of all tests in > tools/build/mk/OptionalObsoleteFiles.inc so that setting > WITHOUT_TESTS=no cleans up /usr/tests. This will be a pain to maintain > and a sure source of inconsistencies. If we could special-case this to > make it more automatic, do you have any suggestions? Is it possible to use the list of current tests and just delete any files which are not listed? We would need some way to have "local" tests but that should not be difficult? -- Eitan Adler From owner-freebsd-testing@FreeBSD.ORG Mon Oct 28 01:31:41 2013 Return-Path: Delivered-To: freebsd-testing@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 77F71F58 for ; Mon, 28 Oct 2013 01:31:41 +0000 (UTC) (envelope-from julio@meroh.net) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DA0DF2910 for ; Mon, 28 Oct 2013 01:31:40 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id x18so2385143lbi.30 for ; Sun, 27 Oct 2013 18:31:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1lPF2dKvq1vwUT5d/cPUCAa+DJlpqtteqJ4SU287m1A=; b=DskZ9ihDrIZAP3ac5RQPHOVl8vSguXAw+P3+BWgJ2jS4uoOWmW2+I45IaVT2oqKxsx SVRQHzRNzH0BwRKmzvZh0oO1dyJ6rgWROWFbUs9iJsffn6EfVZtg/fOUL0AP8wGw0uLL bDHgpYuLLnlZlQx84/ZAuxgV9RGWtPOpzAJDupX/7fkN5IOM69Wr4GJCnFYkJ3OM+ib1 j2fVOwA9PDkPy2qV9qHbJXemZDSTeFfsXMu92/tkVz6jfhMvyICpo2TZ3MEIiVn5RhR0 Qn3nKcxCdq0nSPGoVjIwSp7kJ758gY9PbIBtYLMtWRkXENYhthz6qOqvBm3Uot8aNxZe plVA== X-Gm-Message-State: ALoCoQl217lTSUFdBRSOjoGMbcPDtWUaZgcALjXgNkI2Wbak6GYtZVmNm0HUP45OPjKi/95r/cUA X-Received: by 10.112.136.65 with SMTP id py1mr5892191lbb.4.1382923892094; Sun, 27 Oct 2013 18:31:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.132.135 with HTTP; Sun, 27 Oct 2013 18:31:12 -0700 (PDT) X-Originating-IP: [108.176.158.82] In-Reply-To: References: From: Julio Merino Date: Sun, 27 Oct 2013 21:31:12 -0400 Message-ID: Subject: Re: Plugging ATF tests into the build and other cleanups To: Eitan Adler Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-testing@freebsd.org, Rui Paulo , Simon Gerraty X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 01:31:41 -0000 On Sun, Oct 27, 2013 at 8:25 PM, Eitan Adler wrote: > On Sun, Oct 27, 2013 at 6:12 PM, Julio Merino wrote: >> Hello! >> The one concern I have here is having to keep track of all tests in >> tools/build/mk/OptionalObsoleteFiles.inc so that setting >> WITHOUT_TESTS=no cleans up /usr/tests. This will be a pain to maintain >> and a sure source of inconsistencies. If we could special-case this to >> make it more automatic, do you have any suggestions? > > Is it possible to use the list of current tests and just delete any > files which are not listed? I think what you are suggesting applies to src/ObsoleteFiles.inc, not tools/build/mk/OptionalObsoleteFiles.inc? For deleted tests, I think using src/ObsoleteFiles.inc is fine as usual. Deleted tests have to be removed no matter what the value of MK_TESTS is. If that list gets out of hand at some point we could revisit this, although I'm not sure how you can easily determine the list of "current tests". AFAIK there is no list in src detailing all files that are expected to be installed? My concern is only about the latter at the moment. When MK_TESTS=no, /usr/tests should not exist at all and, therefore, a "make delete-old-files" should wipe it. We can do this as usual, with the functionality in tools/build/mk/OptionalObsoleteFiles.inc to record all files to be deleted, or we can do something different to avoid maintaining the list by hand. A simple "rm -rf ${DESTDIR}/usr/tests" would suffice, but I'm just wondering if that'd be an acceptable thing to do. > We would need some way to have "local" tests but that should not be difficult? You mean tests from ports and/or for manually installed software? Those should all be somewhere in /usr/local/ and we can easily hook them into the test suite. (Hadn't thought about these, but it's easy.) -- Julio Merino / @jmmv From owner-freebsd-testing@FreeBSD.ORG Mon Oct 28 15:47:05 2013 Return-Path: Delivered-To: freebsd-testing@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E85382CC for ; Mon, 28 Oct 2013 15:47:04 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 838D5288B for ; Mon, 28 Oct 2013 15:47:04 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id t61so6691859wes.20 for ; Mon, 28 Oct 2013 08:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QgDALuQNBXpHcBVfbaIuIqLWrby8MC2eKHTMLviljpM=; b=UmP0Md920V7CgMx5OyEbckoR/UUGPzVXr7LfwigUD2O2rNCEkqjVq6DXTr0JL9kBtJ 9/91ABJmV7By8lmsKRZ1eNRdG+PBkrITrsqTb/AP7NeEO9v1I86HmuApMHu1wnmZQAdx eyO8iUlNvLbMwlzNbvfpyzSVsoBOaTirqev8g6ozKOJUrYC/cynm1mj24QdSIiEf2cc/ gAqAzQd02iwHsIWj+twS0fobmUXLWG0Vwi7JHTDB+Vv8O2bipBRrim4RPLS90vLzCfBx O3ZfGXIzMcYFITRLImv48pqYw7yT76+ZAcZKH2MWICDrtwB+bYGPcr7BfKUPBzPeLqrv Afcg== MIME-Version: 1.0 X-Received: by 10.180.198.44 with SMTP id iz12mr9648599wic.32.1382975222844; Mon, 28 Oct 2013 08:47:02 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.171.35 with HTTP; Mon, 28 Oct 2013 08:47:02 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Oct 2013 09:47:02 -0600 X-Google-Sender-Auth: U8av5DktSQhZrgiNPUhElxwJKAE Message-ID: Subject: Re: Plugging ATF tests into the build and other cleanups From: Alan Somers To: Julio Merino Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-testing@freebsd.org" , Rui Paulo , Simon Gerraty X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 15:47:05 -0000 On Sun, Oct 27, 2013 at 7:31 PM, Julio Merino wrote: > On Sun, Oct 27, 2013 at 8:25 PM, Eitan Adler wrote: >> On Sun, Oct 27, 2013 at 6:12 PM, Julio Merino wrote: >>> Hello! >>> The one concern I have here is having to keep track of all tests in >>> tools/build/mk/OptionalObsoleteFiles.inc so that setting >>> WITHOUT_TESTS=no cleans up /usr/tests. This will be a pain to maintain >>> and a sure source of inconsistencies. If we could special-case this to >>> make it more automatic, do you have any suggestions? >> >> Is it possible to use the list of current tests and just delete any >> files which are not listed? > > I think what you are suggesting applies to src/ObsoleteFiles.inc, not > tools/build/mk/OptionalObsoleteFiles.inc? > > For deleted tests, I think using src/ObsoleteFiles.inc is fine as > usual. Deleted tests have to be removed no matter what the value of > MK_TESTS is. If that list gets out of hand at some point we could > revisit this, although I'm not sure how you can easily determine the > list of "current tests". AFAIK there is no list in src detailing all > files that are expected to be installed? > > My concern is only about the latter at the moment. When MK_TESTS=no, > /usr/tests should not exist at all and, therefore, a "make > delete-old-files" should wipe it. We can do this as usual, with the > functionality in tools/build/mk/OptionalObsoleteFiles.inc to record > all files to be deleted, or we can do something different to avoid > maintaining the list by hand. A simple "rm -rf ${DESTDIR}/usr/tests" > would suffice, but I'm just wondering if that'd be an acceptable thing > to do. > >> We would need some way to have "local" tests but that should not be difficult? > > You mean tests from ports and/or for manually installed software? > Those should all be somewhere in /usr/local/ and we can easily hook > them into the test suite. (Hadn't thought about these, but it's > easy.) On our custom version of FreeBSD, we have a few ports that install tests to /usr/local/tests, a top-level Kyuafile at both /usr/tests/Kyuafile and /usr/local/tests/Kyuafile, and a symlink from /usr/tests/local -> /usr/local/tests. It works well. > > -- > Julio Merino / @jmmv > _______________________________________________ > freebsd-testing@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-testing > To unsubscribe, send any mail to "freebsd-testing-unsubscribe@freebsd.org" From owner-freebsd-testing@FreeBSD.ORG Mon Oct 28 23:50:35 2013 Return-Path: Delivered-To: freebsd-testing@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5B643BDB; Mon, 28 Oct 2013 23:50:35 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 24812297F; Mon, 28 Oct 2013 23:50:35 +0000 (UTC) Received: by mail-pb0-f44.google.com with SMTP id rp16so2501551pbb.31 for ; Mon, 28 Oct 2013 16:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uuObe4+TnnsPQzDXfYAOT1Ey6ResFk1bAU/mxqqgGSc=; b=RklW0tp2oFBYo7lNbt0/kCpS7dDJ5RfJ5Q3w5K18k62eJSfYQ9wNvr3ps0PGdJ9l/z eJgFLRg1OUWtULXAe+noc356jYQ+dXSLBJYzgLlq83KdFS9PCxk/OdUeKOSW3Qci2YMN nSLnTb1VI9W4EbOjt/F9tW+OU5XIsy0vqO1o6ulzMuRwrAr3jZd0nsaFcXC2x0SE2qD8 aSKh6PIrmwMsDGSqiX6f4XfCWgK5hGeDnsFFT5pu/Elhb9VzKHjOJUfhI5n/4NsYQPVB oZlcuo90QhxneCCAhP7qfHAUrWoCOWUxhCHohJ6DPIneWeaul4szGeGKHzwlKtBR+4/W FF7w== X-Received: by 10.68.179.4 with SMTP id dc4mr9217427pbc.45.1383004234730; Mon, 28 Oct 2013 16:50:34 -0700 (PDT) Received: from [10.0.1.195] ([64.14.143.130]) by mx.google.com with ESMTPSA id ho3sm31120922pbb.23.2013.10.28.16.50.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Oct 2013 16:50:34 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Plugging ATF tests into the build and other cleanups From: Garrett Cooper In-Reply-To: Date: Mon, 28 Oct 2013 16:51:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alan Somers X-Mailer: Apple Mail (2.1510) Cc: "freebsd-testing@freebsd.org" , Rui Paulo , Simon Gerraty X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 23:50:35 -0000 On Oct 28, 2013, at 8:47 AM, Alan Somers wrote: > On Sun, Oct 27, 2013 at 7:31 PM, Julio Merino wrote: >> On Sun, Oct 27, 2013 at 8:25 PM, Eitan Adler = wrote: >>> On Sun, Oct 27, 2013 at 6:12 PM, Julio Merino = wrote: >>>> Hello! >>>> The one concern I have here is having to keep track of all tests in >>>> tools/build/mk/OptionalObsoleteFiles.inc so that setting >>>> WITHOUT_TESTS=3Dno cleans up /usr/tests. This will be a pain to = maintain >>>> and a sure source of inconsistencies. If we could special-case this = to >>>> make it more automatic, do you have any suggestions? >>>=20 >>> Is it possible to use the list of current tests and just delete any >>> files which are not listed? >>=20 >> I think what you are suggesting applies to src/ObsoleteFiles.inc, not >> tools/build/mk/OptionalObsoleteFiles.inc? >>=20 >> For deleted tests, I think using src/ObsoleteFiles.inc is fine as >> usual. Deleted tests have to be removed no matter what the value of >> MK_TESTS is. If that list gets out of hand at some point we could >> revisit this, although I'm not sure how you can easily determine the >> list of "current tests". AFAIK there is no list in src detailing all >> files that are expected to be installed? >>=20 >> My concern is only about the latter at the moment. When MK_TESTS=3Dno, >> /usr/tests should not exist at all and, therefore, a "make >> delete-old-files" should wipe it. We can do this as usual, with the >> functionality in tools/build/mk/OptionalObsoleteFiles.inc to record >> all files to be deleted, or we can do something different to avoid >> maintaining the list by hand. A simple "rm -rf ${DESTDIR}/usr/tests" >> would suffice, but I'm just wondering if that'd be an acceptable = thing >> to do. >>=20 >>> We would need some way to have "local" tests but that should not be = difficult? >>=20 >> You mean tests from ports and/or for manually installed software? >> Those should all be somewhere in /usr/local/ and we can easily hook >> them into the test suite. (Hadn't thought about these, but it's >> easy.) >=20 > On our custom version of FreeBSD, we have a few ports that install > tests to /usr/local/tests, a top-level Kyuafile at both > /usr/tests/Kyuafile and /usr/local/tests/Kyuafile, and a symlink from > /usr/tests/local -> /usr/local/tests. It works well. It would be nice if this was standardized and documented like with gcc = for instance with its debug lookup paths=85 Thanks! -Garrett= From owner-freebsd-testing@FreeBSD.ORG Mon Oct 28 23:57:12 2013 Return-Path: Delivered-To: freebsd-testing@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2B751DE7; Mon, 28 Oct 2013 23:57:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF09529A9; Mon, 28 Oct 2013 23:57:11 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id w10so5970756pde.17 for ; Mon, 28 Oct 2013 16:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k0ahKReJ44GiPenAeafK/TPiSiFy9WFqDSFS9jDZdw8=; b=eHi1Tk7I4sd+xrXbSvFHb44ypXewPAX3cviiNCWfezxlbdN1Ct0RKf6KQIzSnNXrCi OeBJoiHhSTiboBwtO0fWFyQqiXQn5Zcr+Hk3rD3E75I/wf/+cwyOmrkrzJXxQIy5PB/w +1i2ecjA47vnudKeWj1HazwewxoL9cWyRsScz21vJXIlsJIZqo04e5vyecVW3xCnxvYd ZHM4tACPG0sgC/Wyh/I3dczYAURvsAIuFWbHgOXXhCDQ0Ampbm+0/BUF53tmuEFebCQA 7nmKqDY2hYPcwsm8CpeE10syBbh+m+AK5djCIXmwS9H4moTWLbpXx6XgaJFF1qL6J9rf tbmA== X-Received: by 10.68.253.67 with SMTP id zy3mr5644426pbc.137.1383004631540; Mon, 28 Oct 2013 16:57:11 -0700 (PDT) Received: from [10.0.1.195] ([64.14.143.130]) by mx.google.com with ESMTPSA id y9sm38140197pas.10.2013.10.28.16.57.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Oct 2013 16:57:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Plugging ATF tests into the build and other cleanups From: Garrett Cooper In-Reply-To: Date: Mon, 28 Oct 2013 16:58:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Julio Merino X-Mailer: Apple Mail (2.1510) Cc: freebsd-testing@freebsd.org, Baptiste Daroussin , Rui Paulo , Simon Gerraty X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 23:57:12 -0000 On Oct 27, 2013, at 6:31 PM, Julio Merino wrote: > On Sun, Oct 27, 2013 at 8:25 PM, Eitan Adler = wrote: >> On Sun, Oct 27, 2013 at 6:12 PM, Julio Merino = wrote: >>> Hello! >>> The one concern I have here is having to keep track of all tests in >>> tools/build/mk/OptionalObsoleteFiles.inc so that setting >>> WITHOUT_TESTS=3Dno cleans up /usr/tests. This will be a pain to = maintain >>> and a sure source of inconsistencies. If we could special-case this = to >>> make it more automatic, do you have any suggestions? >>=20 >> Is it possible to use the list of current tests and just delete any >> files which are not listed? >=20 > I think what you are suggesting applies to src/ObsoleteFiles.inc, not > tools/build/mk/OptionalObsoleteFiles.inc? Yes. > For deleted tests, I think using src/ObsoleteFiles.inc is fine as > usual. Deleted tests have to be removed no matter what the value of > MK_TESTS is. If that list gets out of hand at some point we could > revisit this, although I'm not sure how you can easily determine the > list of "current tests". AFAIK there is no list in src detailing all > files that are expected to be installed? >=20 > My concern is only about the latter at the moment. When MK_TESTS=3Dno, > /usr/tests should not exist at all and, therefore, a "make > delete-old-files" should wipe it. We can do this as usual, with the > functionality in tools/build/mk/OptionalObsoleteFiles.inc to record > all files to be deleted, or we can do something different to avoid > maintaining the list by hand. A simple "rm -rf ${DESTDIR}/usr/tests" > would suffice, but I'm just wondering if that'd be an acceptable thing > to do. This could delete local files though, unexpectedly.. What if you were = doing local hacking and your tree was blown away for instance? make = delete-old* protects against that today. This point might be a good point to bring up standardizing packaging in = base; I have an idea of how to design this from a make perspective after = dealing with this pain ad nauseam for Isilon--just wouldn't want to do = the work if another effort was underway. I realize this is an orthogonal = goal, but it would simplify this a lot -- I found it an incredibly pain = in the rear trying to figure out the ad hoc release "packaging" system = and how to make tests fit on release ISO images a few months back. I've = CCed bapt@ just in case; I know that bdrewery is on this list and he = might have some input to provide. Thanks! -Garrett= From owner-freebsd-testing@FreeBSD.ORG Tue Oct 29 20:59:49 2013 Return-Path: Delivered-To: freebsd-testing@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7F636279 for ; Tue, 29 Oct 2013 20:59:49 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2D8CD26CC for ; Tue, 29 Oct 2013 20:59:48 +0000 (UTC) Received: from mail101-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.22; Tue, 29 Oct 2013 20:59:42 +0000 Received: from mail101-ch1 (localhost [127.0.0.1]) by mail101-ch1-R.bigfish.com (Postfix) with ESMTP id DA6863A00A5; Tue, 29 Oct 2013 20:59:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zz146fI1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de097hz2fh2a8h839hd25hf0ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2fh1b88h1fb3h1d0ch1d2eh1d3fh1de2h1dfeh1dffh1e23h1fe8h1ff5h2218h2216h1155h) Received-SPF: pass (mail101-ch1: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=sjg@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail101-ch1 (localhost.localdomain [127.0.0.1]) by mail101-ch1 (MessageSwitch) id 1383080380375585_14777; Tue, 29 Oct 2013 20:59:40 +0000 (UTC) Received: from CH1EHSMHS040.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241]) by mail101-ch1.bigfish.com (Postfix) with ESMTP id 46D43380033; Tue, 29 Oct 2013 20:59:40 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.54) by CH1EHSMHS040.bigfish.com (10.43.69.249) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 29 Oct 2013 20:59:39 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 29 Oct 2013 13:59:37 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r9TKxaL19590; Tue, 29 Oct 2013 13:59:36 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 0C1905807E; Tue, 29 Oct 2013 13:59:36 -0700 (PDT) To: Julio Merino Subject: Re: Plugging ATF tests into the build and other cleanups In-Reply-To: References: Comments: In-reply-to: Julio Merino message dated "Sun, 27 Oct 2013 21:31:12 -0400." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Tue, 29 Oct 2013 13:59:36 -0700 Message-ID: <20131029205936.0C1905807E@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: freebsd-testing@freebsd.org, Rui Paulo , sjg@juniper.net X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:59:49 -0000 On Sun, 27 Oct 2013 21:31:12 -0400, Julio Merino writes: >revisit this, although I'm not sure how you can easily determine the >list of "current tests". AFAIK there is no list in src detailing all >files that are expected to be installed? So I know this probably doesn't help but.... As I think I've mentioned in our build, we build tests and stage them automatically to a stage tree ($SB/obj/stage/$MACHINE/usr/tests/...) unless building for the pseudo machine 'host' in which case the tests are run in-place as part of the build - tests fail, build fails. Anyway, before the makefile that does "packaging" for the tests, another does a scan of $SB/obj/stage/$MACHINE/usr/tests/ to find all the tests and build the manifest that will be used for them. This avoids having to maintain a list, and makes adding tests trivial. >My concern is only about the latter at the moment. When MK_TESTS=no, >/usr/tests should not exist at all and, therefore, a "make >delete-old-files" should wipe it. We can do this as usual, with the Obviously this really only matters if/when one does 'make delete-old-files -DWITHOUT_TESTS' >functionality in tools/build/mk/OptionalObsoleteFiles.inc to record >all files to be deleted, or we can do something different to avoid >maintaining the list by hand. A simple "rm -rf ${DESTDIR}/usr/tests" >would suffice, but I'm just wondering if that'd be an acceptable thing >to do. Not quite within the context of delete-old-files given the way it works, but doesn't mean one couldn't add delete-old-dirs-rmrf with its own list for input eg. OLD_DIRS_RMRF >> We would need some way to have "local" tests but that should not be difficul >t? > >You mean tests from ports and/or for manually installed software? >Those should all be somewhere in /usr/local/ and we can easily hook >them into the test suite. (Hadn't thought about these, but it's >easy.) The model I mentioned above "just works" in this case. Not much help though until using all the goodies on projects/bmake (the above isn't there either yet - hope to fix that soon). From owner-freebsd-testing@FreeBSD.ORG Tue Oct 29 21:22:40 2013 Return-Path: Delivered-To: freebsd-testing@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0FB8C4FE for ; Tue, 29 Oct 2013 21:22:40 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6CE0128F2 for ; Tue, 29 Oct 2013 21:22:39 +0000 (UTC) Received: from mail18-am1-R.bigfish.com (10.3.201.227) by AM1EHSOBE015.bigfish.com (10.3.207.137) with Microsoft SMTP Server id 14.1.225.22; Tue, 29 Oct 2013 20:37:09 +0000 Received: from mail18-am1 (localhost [127.0.0.1]) by mail18-am1-R.bigfish.com (Postfix) with ESMTP id F3D5630006A; Tue, 29 Oct 2013 20:37:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz8275ch17326ah1de097h186068hz2fh2a8h839hd25hf0ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2fh1b88h1fb3h1d0ch1d2eh1d3fh1de2h1dfeh1dffh1e23h1fe8h1ff5h2218h2216h1155h) Received-SPF: pass (mail18-am1: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=sjg@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail18-am1 (localhost.localdomain [127.0.0.1]) by mail18-am1 (MessageSwitch) id 1383079027487551_32023; Tue, 29 Oct 2013 20:37:07 +0000 (UTC) Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.252]) by mail18-am1.bigfish.com (Postfix) with ESMTP id 6FC84E00DF; Tue, 29 Oct 2013 20:37:07 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.53) by AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 29 Oct 2013 20:37:06 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 29 Oct 2013 13:37:05 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r9TKawL05029; Tue, 29 Oct 2013 13:36:59 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 75BF35807E; Tue, 29 Oct 2013 13:36:58 -0700 (PDT) To: Julio Merino Subject: Re: Plugging ATF tests into the build and other cleanups In-Reply-To: References: Comments: In-reply-to: Julio Merino message dated "Sun, 27 Oct 2013 18:12:12 -0400." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Tue, 29 Oct 2013 13:36:58 -0700 Message-ID: <20131029203658.75BF35807E@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: freebsd-testing@freebsd.org, Rui Paulo , sjg@juniper.net X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 21:22:40 -0000 On Sun, 27 Oct 2013 18:12:12 -0400, Julio Merino writes: >The one concern I have here is having to keep track of all tests in >tools/build/mk/OptionalObsoleteFiles.inc so that setting >WITHOUT_TESTS=no cleans up /usr/tests. This will be a pain to maintain Yes. >and a sure source of inconsistencies. If we could special-case this to >make it more automatic, do you have any suggestions? Iff ATF/Kyua were the only thing populating /usr/tests/ you could just rm -rf that dir, but that's not how delete-old-* works else KYUAFILES!= cd $DESTDIR/ && find usr/tests -name Kyuafile OLD_DIRS+= ${KYUAFILES:H} would be all you'd need. You can't even do OLD_FILES+= ${KYUAFILES:H}/* It could be that a new delete-old- target might be useful, >As usual: http://portal.meroh.net/~jmmv/freebsd-testing/ remove-without-atf.diff looks ok - assuming folk are ok with s,ATF,TESTS, freebsd-testing/recurse-subdir.diff I'm not so crazy about. What's wrong with requiring folk to set TESTS_SUBDIR[S] ? freebsd-testing/move-kyuafiles.diff I'm also not crazy about this one (the change to lib/Makefile) What is the expected use? and why can't everything that is needed be done within the context of the individual lib/*/tests/ dir? That's how we are doing it. build-atf-tests.diff FWIW I prefer ${.CURDIR:H:H} etc rather than ${.CURDIR}/../.. makes for much neater paths (also bit quicker on nfs) It would be nice to be able to rely on SRCTOP being correctly set (easy with bmake, have to think about fmake...) ATF_SRC = ${SRCTOP}/contrib/atf could then be set on one place but otherwise ok. From owner-freebsd-testing@FreeBSD.ORG Tue Oct 29 21:46:48 2013 Return-Path: Delivered-To: freebsd-testing@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 48C1B328 for ; Tue, 29 Oct 2013 21:46:48 +0000 (UTC) (envelope-from julio@meroh.net) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B02012AE5 for ; Tue, 29 Oct 2013 21:46:47 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id u14so542546lbd.36 for ; Tue, 29 Oct 2013 14:46:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Njg1hDGMuokGg9R/2foH6xQNkfHNtuHUpgKioPGIcaM=; b=RbQB433lLU6dfMHdIkwiCmrkQ51F3C8jQAwpnfFLze70Kld08GqhC0GtjcV/nuH/ze 8Vd53ml/yrf7dVLZyACi1M2Kxyvy+Mk6Tfqu964ifaieLlVJg9u1WvYj9XK5/xKApEew SLSkYpMqllEhvzpjMtyyE6cb8p8/mySyNX1G1Rmp+AflEsn6gQ8oRtgDcv9uYcaBqMrN XuVBSVbiukfPKLGZmUETmeYdCBR04HcbgSHkSI50PRjzUAlcoEdKCm1CaM6AC+bMD4r9 /2jCc/5V/EiukmXzwJot1QrD2KF6eV57gswKy0qltz9fZ86C+lF8/P26gDdeg3w6ufDE rI1w== X-Gm-Message-State: ALoCoQlB4BWPxDZmRtDnnwWQhYSnO6Kv5SM6R9bWTmgj3SrLcVJHdS+V0p3NqqFva+veDPKDh6XC X-Received: by 10.152.29.38 with SMTP id g6mr913197lah.25.1383083199482; Tue, 29 Oct 2013 14:46:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.132.135 with HTTP; Tue, 29 Oct 2013 14:46:19 -0700 (PDT) X-Originating-IP: [172.26.105.74] In-Reply-To: <20131029203658.75BF35807E@chaos.jnpr.net> References: <20131029203658.75BF35807E@chaos.jnpr.net> From: Julio Merino Date: Tue, 29 Oct 2013 17:46:19 -0400 Message-ID: Subject: Re: Plugging ATF tests into the build and other cleanups To: "Simon J. Gerraty" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-testing@freebsd.org, Rui Paulo X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 21:46:48 -0000 On Tue, Oct 29, 2013 at 4:36 PM, Simon J. Gerraty wrote: > > On Sun, 27 Oct 2013 18:12:12 -0400, Julio Merino writes: >>The one concern I have here is having to keep track of all tests in >>tools/build/mk/OptionalObsoleteFiles.inc so that setting >>WITHOUT_TESTS=no cleans up /usr/tests. This will be a pain to maintain > > Yes. > >>and a sure source of inconsistencies. If we could special-case this to >>make it more automatic, do you have any suggestions? > > Iff ATF/Kyua were the only thing populating /usr/tests/ you could just > rm -rf that dir, but that's not how delete-old-* works else > > KYUAFILES!= cd $DESTDIR/ && find usr/tests -name Kyuafile > OLD_DIRS+= ${KYUAFILES:H} > > would be all you'd need. > You can't even do OLD_FILES+= ${KYUAFILES:H}/* I'm confused... Is that "can't" supposed to be "can"? Or in other words, do you mean that this would or would not work if we assumed that ATF/Kyua are the only thing populating /usr/tests ? That's part of the rationale for the next patch: to make /usr/tests/ conditional on a single knob (WITH_TESTS) so that such assumptions can be made: either you install the full test suite or you don't. I don't think it makes sense to support in-between cases... or at least not until a real need for it appears). > It could be that a new delete-old- target might be useful, Would be nice if it weren't necessary though. I think delete-old-files should deal with this case just as it does for any other WITH_* knob so that there are no extra steps to the rebuild procedure. >>As usual: http://portal.meroh.net/~jmmv/freebsd-testing/ > > remove-without-atf.diff > > looks ok - assuming folk are ok with s,ATF,TESTS, > > freebsd-testing/recurse-subdir.diff > > I'm not so crazy about. > What's wrong with requiring folk to set TESTS_SUBDIR[S] ? Because SUBDIR and TESTS_SUBDIRS serve different purposes. With SUBDIR you are telling make (and only make) that it has to recurse into those directories. With TESTS_SUBDIRS you are telling both make and kyua to recurse into the subdirectories. This is useful to build helper binaries/libraries/etc that live in subdirectories without tests (which is necessary when bsd.*.mk don't play well with the test stuff); however, this use-case is not needed yet so we can ignore it for now. The real reason I tossed in this patch here is the following. In the current patchset, this is useful in, for example, src/lib/atf/Makefile (see last patch) : this file needs to generate a Kyuafile that registers its 3 subdirectories (libatf-c, libatf-c++ and test-programs) so that the recursion can be performed at runtime. There is no need to list those as TESTS_SUBDIRS because they are already in SUBDIR. There are some alternatives to this behavior: 1. Move the generation of the Kyuafile to src/lib/atf/tests/Makefile. But if you do that, you cannot get the automatic generation to work because that tests/ directory does not have any children (and thus the automatic generation code has no idea about what to do). 2. Manually set TESTS_SUBDIR in src/lib/atf/Makefile to SUBDIR... which would be suboptimal because this is something that could be done automatically (this patch). 3. Make src/lib/atf/tests/Makefile install a generic Kyuafile that discovers its directories, just like /usr/tests/Kyuafile and /usr/tests/lib/Kyuafile do. This is a reasonable optional and would follow your comments below of keeping stuff in tests/ > freebsd-testing/move-kyuafiles.diff > > I'm also not crazy about this one (the change to lib/Makefile) > What is the expected use? To populate /usr/tests/lib accordingly. You need: /usr/tests/Kyuafile - auto-recurse into directories /usr/tests/lib/Kyuafile - auto-recurse into directories /usr/tests/lib/libc/Kyuafile - list of tests to run and possibly other subdirectories and that /usr/tests/lib/Kyuafile has to come from somewhere. I think that doing this from src/tests/lib/, as I did it originally, is confusing and it seems to me that doing it from somewhere within src/lib/ is clearer. The rationale would be that everything required to create /usr/tests/lib/ would happen from a single place: src/lib/ . (More below.) > and why can't everything that is needed be > done within the context of the individual lib/*/tests/ dir? > That's how we are doing it. We could do this from src/lib/tests/ as easily; didn't think about it. Gave this a try and updated the patches accordingly; check them out. Still open is the question if we should do the same for src/lib/atf/Makefile et. al. I suspect the answer is yes, but then there is the issue mentioned above of the Kyuafile auto-generation. (Haven't done it yet as I don't have the time now and would appreciate your input.) > build-atf-tests.diff > > FWIW I prefer ${.CURDIR:H:H} etc rather than ${.CURDIR}/../.. > makes for much neater paths (also bit quicker on nfs) Done; didn't think about that. > It would be nice to be able to rely on SRCTOP being correctly set > (easy with bmake, have to think about fmake...) > > ATF_SRC = ${SRCTOP}/contrib/atf > > could then be set on one place > but otherwise ok. Indeed, having a SRCTOP would have made things easier... but I didn't find that available. Note: I have applied some of your suggestions to the existing patches but some things still remain open so don't bother doing an in-depth review again because they are broken. However, I gotta go now and I'd prefer to send this out for further comments while I have your attention ;) -- Julio Merino / @jmmv From owner-freebsd-testing@FreeBSD.ORG Wed Oct 30 02:48:45 2013 Return-Path: Delivered-To: freebsd-testing@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8230B470 for ; Wed, 30 Oct 2013 02:48:45 +0000 (UTC) (envelope-from julio@meroh.net) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0DABE2C3B for ; Wed, 30 Oct 2013 02:48:44 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id ea20so589939lab.15 for ; Tue, 29 Oct 2013 19:48:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZnYevcLzcRrCWnq5hBnRM1rcSyfCjp6iDBXIXcXEmlo=; b=fvOBbdHG/wyHzGspDMI67odFjKu9ckDSbSWjJNB+2Rk26DuEeuNlZl5fAKEj+/giHS ka19dkIJBsUjTew9OJAWV7WKsmej+/TLPvYyQFFlEqgxy3UTqLqWq6Mf5jI6V45WCvSz qh6Of5F/BrA6BtXeKUCQiqWGmlBAPcGG361gGo+UQuBI2pDEUKP3AMhB9bgKhaUlpElJ orwSbBappKZMSnBxSe9kMu9oC+Tj1SUgiYo9sZFJi8ZilpMD2X91vCuyzN+GkT3/FLW8 eV0bsXPsYpd0BM+YBvogYc3oWomiW114TmdXFPi65FinQRG5iWnS2pmc7SAv2WnYloFM CM6g== X-Gm-Message-State: ALoCoQnjySRD99dfkYrXIjSsW+70sPd1Xsy4US9nreAUIoqLVVZ7VPuV0uJvxMjpkppjNYGuXFP/ X-Received: by 10.152.225.139 with SMTP id rk11mr1526818lac.27.1383101317140; Tue, 29 Oct 2013 19:48:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.132.135 with HTTP; Tue, 29 Oct 2013 19:48:17 -0700 (PDT) X-Originating-IP: [108.176.158.82] In-Reply-To: <20131029203658.75BF35807E@chaos.jnpr.net> References: <20131029203658.75BF35807E@chaos.jnpr.net> From: Julio Merino Date: Tue, 29 Oct 2013 22:48:17 -0400 Message-ID: Subject: Re: Plugging ATF tests into the build and other cleanups To: "Simon J. Gerraty" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-testing@freebsd.org, Rui Paulo X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 02:48:45 -0000 Please disregard my previous reply! Turns out I could get to fixing the remaining rough edges earlier than I thought and thus some of the previous comments are already obsolete. I've replied below to your original mail and copy/pasted my previous replies where it made sense; in other places I've just rewritten them. The patches have been updated. On Tue, Oct 29, 2013 at 4:36 PM, Simon J. Gerraty wrote: > > On Sun, 27 Oct 2013 18:12:12 -0400, Julio Merino writes: >>The one concern I have here is having to keep track of all tests in >>tools/build/mk/OptionalObsoleteFiles.inc so that setting >>WITHOUT_TESTS=no cleans up /usr/tests. This will be a pain to maintain > > Yes. > >>and a sure source of inconsistencies. If we could special-case this to >>make it more automatic, do you have any suggestions? > > Iff ATF/Kyua were the only thing populating /usr/tests/ you could just > rm -rf that dir, but that's not how delete-old-* works else > > KYUAFILES!= cd $DESTDIR/ && find usr/tests -name Kyuafile > OLD_DIRS+= ${KYUAFILES:H} > > would be all you'd need. > You can't even do OLD_FILES+= ${KYUAFILES:H}/* I'm confused... Is that "can't" supposed to be "can"? I just gave this a try and it seems to work. Much simpler to manage. But this is obviously tied to the assumption that /usr/tests/ depends on the WITH_TESTS knob only.... which I think is a fair assumption to make: either you install the full test suite or you don't. Trying to support in-between cases that don't yet exist just makes things more complex; could be revised in the future if/when needed. And hence, this was mostly the rationale for the next patch. > It could be that a new delete-old- target might be useful, Would be nice if it weren't necessary though. I think delete-old-files should deal with this case just as it does for any other WITH_* knob so that there are no extra steps to the rebuild procedure. >>As usual: http://portal.meroh.net/~jmmv/freebsd-testing/ > > remove-without-atf.diff > > looks ok - assuming folk are ok with s,ATF,TESTS, > > freebsd-testing/recurse-subdir.diff > > I'm not so crazy about. > What's wrong with requiring folk to set TESTS_SUBDIR[S] ? See my previous email if you wish, but I have dropped this from the patchset. The other changes I've done below have made this unnecessary... for now at least! > freebsd-testing/move-kyuafiles.diff > > I'm also not crazy about this one (the change to lib/Makefile) > What is the expected use? To populate /usr/tests/lib accordingly. You need: /usr/tests/Kyuafile - auto-recurse into directories /usr/tests/lib/Kyuafile - auto-recurse into directories /usr/tests/lib/libc/Kyuafile - list of tests to run and possibly other subdirectories and that /usr/tests/lib/Kyuafile has to come from somewhere. I think that doing this from src/tests/lib/, as I did it originally, is confusing and it seems to me that doing it from somewhere within src/lib/ is clearer. The rationale would be that everything required to create /usr/tests/lib/ would happen from a single place: src/lib/ . (More below.) > and why can't everything that is needed be > done within the context of the individual lib/*/tests/ dir? > That's how we are doing it. We could do this from src/lib/tests/ as easily; didn't think about it. Gave this a try and updated the patches accordingly. Did the same for src/libexec/tests/, src/usr.bin/tests/ and the 'atf' subdirectories in each of the three. I think this is reasonable enough and should play well with your ideas. > build-atf-tests.diff > > FWIW I prefer ${.CURDIR:H:H} etc rather than ${.CURDIR}/../.. > makes for much neater paths (also bit quicker on nfs) Done; didn't think about that. > It would be nice to be able to rely on SRCTOP being correctly set > (easy with bmake, have to think about fmake...) > > ATF_SRC = ${SRCTOP}/contrib/atf > > could then be set on one place > but otherwise ok. Indeed, having a SRCTOP would have made things easier... but I didn't find that available. OK, patches ready for a second look. Still not ready for submission though as I have not yet had the time to look at the test failures themselves. -- Julio Merino / @jmmv From owner-freebsd-testing@FreeBSD.ORG Wed Oct 30 22:26:31 2013 Return-Path: Delivered-To: freebsd-testing@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3B81EB8 for ; Wed, 30 Oct 2013 22:26:31 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9925B28B3 for ; Wed, 30 Oct 2013 22:26:30 +0000 (UTC) Received: from mail5-db8-R.bigfish.com (10.174.8.225) by DB8EHSOBE011.bigfish.com (10.174.4.74) with Microsoft SMTP Server id 14.1.225.22; Wed, 30 Oct 2013 21:25:58 +0000 Received: from mail5-db8 (localhost [127.0.0.1]) by mail5-db8-R.bigfish.com (Postfix) with ESMTP id 2D7DBC001CB; Wed, 30 Oct 2013 21:25:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de097hz2fh2a8h839hd25hf0ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2fh1b88h1fb3h1d0ch1d2eh1d3fh1de2h1dfeh1dffh1e23h1fe8h1ff5h2218h2216h1155h) Received-SPF: pass (mail5-db8: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=sjg@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail5-db8 (localhost.localdomain [127.0.0.1]) by mail5-db8 (MessageSwitch) id 1383168356853304_25803; Wed, 30 Oct 2013 21:25:56 +0000 (UTC) Received: from DB8EHSMHS015.bigfish.com (unknown [10.174.8.243]) by mail5-db8.bigfish.com (Postfix) with ESMTP id C1BE128004B; Wed, 30 Oct 2013 21:25:56 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.52) by DB8EHSMHS015.bigfish.com (10.174.4.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 30 Oct 2013 21:25:53 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 30 Oct 2013 14:25:49 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r9UIF8L72377; Wed, 30 Oct 2013 11:15:15 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 84F085807E; Wed, 30 Oct 2013 11:15:08 -0700 (PDT) To: Julio Merino Subject: Re: Plugging ATF tests into the build and other cleanups In-Reply-To: References: <20131029203658.75BF35807E@chaos.jnpr.net> Comments: In-reply-to: Julio Merino message dated "Tue, 29 Oct 2013 17:46:19 -0400." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Wed, 30 Oct 2013 11:15:08 -0700 Message-ID: <20131030181508.84F085807E@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: freebsd-testing@freebsd.org, Rui Paulo , sjg@juniper.net X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 22:26:31 -0000 On Tue, 29 Oct 2013 17:46:19 -0400, Julio Merino writes: >> You can't even do OLD_FILES+= ${KYUAFILES:H}/* > >I'm confused... Is that "can't" supposed to be "can"? Or in other >words, do you mean that this would or would not work if we assumed >that ATF/Kyua are the only thing populating /usr/tests ? No it wouldn't work - the existing delete-old-* targets are very careful about only deleting what was explicitly listed. That's probably a good thing. >That's part of the rationale for the next patch: to make /usr/tests/ >conditional on a single knob (WITH_TESTS) so that such assumptions can >be made: either you install the full test suite or you don't. I don't You could make that argument yes, and further, if folk want their own test suites they could be told to put them somewhere else. Since this isn't critical one way or the other yet, I'd leave some time for folk to ponder/discuss - ie. just ignore cleaning /usr/tests for now. >> freebsd-testing/recurse-subdir.diff >> >> I'm not so crazy about. >> What's wrong with requiring folk to set TESTS_SUBDIR[S] ? > >Because SUBDIR and TESTS_SUBDIRS serve different purposes. With This patch seems to blur that distinction no? >In the current patchset, this is useful in, for example, >src/lib/atf/Makefile (see last patch) : this file needs to generate a >Kyuafile that registers its 3 subdirectories (libatf-c, libatf-c++ and >test-programs) so that the recursion can be performed at runtime. >There is no need to list those as TESTS_SUBDIRS because they are >already in SUBDIR. But for this corner case, listing those dirs in TESTS_SUBDIRS (despite also being in SUBDIR) would do no great harm, and would avoid the need to blur the distiction noted above. >There are some alternatives to this behavior: > >1. Move the generation of the Kyuafile to src/lib/atf/tests/Makefile. >But if you do that, you cannot get the automatic generation to work >because that tests/ directory does not have any children (and thus the >automatic generation code has no idea about what to do). I'm not sure I fully understand the issue (given what we are doing - see below). >2. Manually set TESTS_SUBDIR in src/lib/atf/Makefile to SUBDIR... >which would be suboptimal because this is something that could be done >automatically (this patch). Optimizing for corner cases isn't necessarily a good idea. If it turns out that this is a common issue, we can always revisit. So this (or the next) would be my suggestion - for now. >3. Make src/lib/atf/tests/Makefile install a generic Kyuafile that >discovers its directories, just like /usr/tests/Kyuafile and >/usr/tests/lib/Kyuafile do. This is a reasonable optional and would >follow your comments below of keeping stuff in tests/ This is what we actually do. Before packaging tests, a generic Atffile is dropped into each dir under ${STAGE_OBJTOP}/usr/tests/ that does not already have one, this seems to work ok. >> freebsd-testing/move-kyuafiles.diff >> >> I'm also not crazy about this one (the change to lib/Makefile) >> What is the expected use? > >To populate /usr/tests/lib accordingly. You need: > >/usr/tests/Kyuafile - auto-recurse into directories >/usr/tests/lib/Kyuafile - auto-recurse into directories >/usr/tests/lib/libc/Kyuafile - list of tests to run and possibly other >subdirectories >and that /usr/tests/lib/Kyuafile has to come from somewhere. I think Sure, but if Kyuafile works anything like Atffile, a generic boilerplate one would do? and this could be handled from almost anywhere. Since we (junos - and same in projects/bmake) ignore intermediate makefiles like lib/ etc, that wouldn't be my choice. Doing it in a leaf dir, works just as well and is then independent of the orchestration of the build. >We could do this from src/lib/tests/ as easily; didn't think about it. > Gave this a try and updated the patches accordingly; check them out. Will do. >Still open is the question if we should do the same for >src/lib/atf/Makefile et. al. I suspect the answer is yes, but then >there is the issue mentioned above of the Kyuafile auto-generation. >(Haven't done it yet as I don't have the time now and would appreciate >your input.) All of the Atffiles in our stage tree are autogenerated. The leaf dirs usr/tests/bin/cat/Atffile are done by atf.test.mk: $ cat ../obj/stage/i386/usr/tests/bin/cat/Atffile Content-Type: application/X-atf-atffile; version="1" # Automatically generated by atf-test.mk. prop: test-suite = "FreeBSD" tp: t_cat $ and the intermediate dirs by the method mentioned above $ cat ../obj/stage/i386/usr/tests/bin/Atffile Content-Type: application/X-atf-atffile; version="1" prop: test-suite = "FreeBSD" tp-glob: * $ ls -li ../obj/stage/i386/usr/tests/bin/Atffile 93925694 -rw-r--r-- 26 sjg wheel 94 Sep 17 14:27 ../obj/stage/i386/usr/tests/bin/Atffile $ cat ../obj/stage/i386/usr/tests/bin/Atffile.dirdep juniper/pkgs/os-tests/finish.i386 $ that last let's you know who put it there. >Indeed, having a SRCTOP would have made things easier... but I didn't >find that available. No, not yet. It is needed for dirdeps.mk though. >Note: I have applied some of your suggestions to the existing patches >but some things still remain open so don't bother doing an in-depth >review again because they are broken. However, I gotta go now and I'd >prefer to send this out for further comments while I have your >attention ;) Sure - thanks very much for your help. --sjg From owner-freebsd-testing@FreeBSD.ORG Fri Nov 1 20:00:01 2013 Return-Path: Delivered-To: freebsd-testing@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 58F56134 for ; Fri, 1 Nov 2013 20:00:01 +0000 (UTC) (envelope-from julio@meroh.net) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D9BE724BD for ; Fri, 1 Nov 2013 20:00:00 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id y6so3857112lbh.11 for ; Fri, 01 Nov 2013 12:59:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=R6587t6OZdTuCQlHH1aE/ZYUPCBI/bpXK9ERUSSjhrs=; b=fMnQfpvfDx3kT6glUenKLTjkSfJLB0hHJy91dGw2do8Imw+39PtGtzPWrLXCGydXck ahBx0wEYp98KqcOotJnGrxLBFo4yHkUFws0y2rtE2lug1e1Zy0BGsnspNrWHvvZ2mjPt ilg7NsT+MaASCOkCEYrSLm/ifg982oqz0ORI9gGQo8tQ2M6It2xys3El0+aXokE9xeVS tHuHWVfaXjurWO94BEQhGv3SlqNDlDrVz4KD0b3uUCKmhlIPglA5yZ07CQiCJl4eInTy w3mMjDMk25/CjChWXudXfFuiHvf9PS7kbx82lnBwqE/9Sg5+LXepXGZZhcdtcvU5Ux/J bilQ== X-Gm-Message-State: ALoCoQmm8ytEq/Fg/tll3urCO55/kIg37AcD1EtloZzX7iDKnhfM7te3q9cg3ZKG+YqKa8HrvWT2 X-Received: by 10.112.210.66 with SMTP id ms2mr583235lbc.51.1383335992129; Fri, 01 Nov 2013 12:59:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.132.135 with HTTP; Fri, 1 Nov 2013 12:59:32 -0700 (PDT) X-Originating-IP: [2620:0:1003:1007:118a:cb85:ffd3:6ebd] In-Reply-To: <20131030181508.84F085807E@chaos.jnpr.net> References: <20131029203658.75BF35807E@chaos.jnpr.net> <20131030181508.84F085807E@chaos.jnpr.net> From: Julio Merino Date: Fri, 1 Nov 2013 15:59:32 -0400 Message-ID: Subject: Re: Plugging ATF tests into the build and other cleanups To: "Simon J. Gerraty" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-testing@freebsd.org, Rui Paulo X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 20:00:01 -0000 On Wed, Oct 30, 2013 at 2:15 PM, Simon J. Gerraty wrote: > > On Tue, 29 Oct 2013 17:46:19 -0400, Julio Merino writes: >>> freebsd-testing/move-kyuafiles.diff >>> >>> I'm also not crazy about this one (the change to lib/Makefile) >>> What is the expected use? >> >>To populate /usr/tests/lib accordingly. You need: >> >>/usr/tests/Kyuafile - auto-recurse into directories >>/usr/tests/lib/Kyuafile - auto-recurse into directories >>/usr/tests/lib/libc/Kyuafile - list of tests to run and possibly other >>subdirectories >>and that /usr/tests/lib/Kyuafile has to come from somewhere. I think > > Sure, but if Kyuafile works anything like Atffile, a generic boilerplate > one would do? and this could be handled from almost anywhere. > Since we (junos - and same in projects/bmake) ignore intermediate > makefiles like lib/ etc, that wouldn't be my choice. Aha! I think the "ignore intermediate makefiles" part is the key piece I was missing to understand your build system. >>Note: I have applied some of your suggestions to the existing patches >>but some things still remain open so don't bother doing an in-depth >>review again because they are broken. However, I gotta go now and I'd >>prefer to send this out for further comments while I have your >>attention ;) > > Sure - thanks very much for your help. FYI: Please note that I already sent another message with more complete responses. You might have missed it since they were both similar in content and possibly strangely threaded. -- Julio Merino / @jmmv