From owner-freebsd-testing@FreeBSD.ORG Sun Nov 24 22:39:57 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 ESMTPS id 93BBA5C4 for ; Sun, 24 Nov 2013 22:39:57 +0000 (UTC) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 572B829C8 for ; Sun, 24 Nov 2013 22:39:57 +0000 (UTC) Received: by mail-yh0-f48.google.com with SMTP id f73so2325665yha.7 for ; Sun, 24 Nov 2013 14:39:56 -0800 (PST) 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=15pBijMEt3N2ar+UD+0rf8gOF0RRXTHJtPdsI6pdHCM=; b=vmH3MsfrdWdE5bpfymuYaW9/7P8Ukt7f7vyHI9TpCwTqVMrWgvVvx3JD4c8JHBDibc +JOfEFRtCIWt+JbQnBLpK6pPkFm9etcNF6CjhV4C2HGiGLar/DrtROa2wZrx6pbaIxao ZV/B5zfsVXhnA7gaNRgNokI5T1yiTKzUQ0VYcDHoRaJDY/kGzVMUcdu4FOd5yGdvPO/C q4o60NlboXdQjdCmGBmSpIxPMSDJn31DRWlxhCYv2OF+PFYp9JPPD0VhN5I6N+gt6bWz LTMOVpz51PpY+C6miVzgkel09ZdMP/ATtRAhJw1CHZygkUlhcL5I+RFGh9cUTnYGPl2B Zojw== X-Received: by 10.236.85.97 with SMTP id t61mr24355038yhe.11.1385332796572; Sun, 24 Nov 2013 14:39:56 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:608b:3f59:7890:c8fe? ([2601:8:ab80:7d6:608b:3f59:7890:c8fe]) by mx.google.com with ESMTPSA id h23sm13462008yhc.0.2013.11.24.14.39.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Nov 2013 14:39:56 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: Confusion over BSD.tests.dist From: Garrett Cooper In-Reply-To: Date: Sun, 24 Nov 2013 14:39:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <500AA3D4-6910-406A-A093-1B925DF0612D@gmail.com> References: <83E6FED5-2E76-4E43-9547-C0DC1C90DBBD@gmail.com> To: Julio Merino X-Mailer: Apple Mail (2.1822) Cc: freebsd-testing@freebsd.org X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 22:39:57 -0000 On Nov 24, 2013, at 2:24 PM, Julio Merino wrote: > On Sun, Nov 24, 2013 at 5:08 PM, Garrett Cooper = wrote: >> On Nov 24, 2013, at 2:04 PM, Julio Merino wrote: >>> Is TESTSBASE supposed to be customizable? (And before answering = that: >>=20 >> It can be: >>=20 >> # grep -r TESTSBASE share/mk >> share/mk/bsd.README:TESTSDIR Target directory relative to = ${TESTSBASE} for tests and >> share/mk/bsd.own.mk:TESTSBASE?=3D /usr/tests >=20 > I know it _can_ be, but the question is: do we want to support that as > a use case? I'm not sure why anybody would want to move /usr/tests > anywhere else. If there is no real reason other than "just because", > I don't think the build system should make any accommodations to make > it trivial. (Because if it's trivial, people _will_ move it and when > things break, it's one more thing to support in bug reports.) Fair enough. The problem is that there are some organizations (like the = one I just left =97 EMC) that use other paths for testing (i.e. not = /usr/tests) because adjusting existing infrastructure to match new stuff = is difficult, introduces unnecessary risk, and could break generic = tools. >>> are things like LIBDIR or INCLUDEDIR user-tunabale?) >>=20 >> Those are user tunable too, but generally not tweaked, except when = dealing with packages that use bsd.*.mk (e.g. ports): >>=20 >> # egrep --include \*.mk -r '^INCLUDEDIR|^LIBDIR' share/mk >> share/mk/bsd.own.mk:LIBDIR?=3D /usr/lib >> share/mk/bsd.own.mk:INCLUDEDIR?=3D /usr/include >=20 > Right, so they are tunable when bsd.*.mk are abused to build things > from ports (and in that case mtree doesn't apply). But I believe they > are not tunable to tell the base system where the libraries or headers > should be; if they were, I'm pretty sure things would break in obscure > ways and it'd be a "support" headache. It=92s not really abuse; there are also some packagers/third party = groups that implement bsd.*.mk properly with the intent to integrate = better into *BSD (by and large the Makefile snippets are consistent = between the BSDs in many cases, so there=92s some degree of = portability), in part because the original upstream source may have done = such a shoddy job writing configure scripts or were so Linux centric = that it=92s better to write something simple from scratch for an initial = port. Cheers! -Garrett=