Confusion over BSD.tests.dist

Garrett Cooper yaneurabeya at
Sun Nov 24 22:39:57 UTC 2013

On Nov 24, 2013, at 2:24 PM, Julio Merino <julio at> wrote:

> On Sun, Nov 24, 2013 at 5:08 PM, Garrett Cooper <yaneurabeya at> wrote:
>> On Nov 24, 2013, at 2:04 PM, Julio Merino <julio at> wrote:
>>> Is TESTSBASE supposed to be customizable?  (And before answering that:
>> It can be:
>> # grep -r TESTSBASE share/mk
>> share/mk/bsd.README:TESTSDIR    Target directory relative to ${TESTSBASE} for tests and
>> share/mk/ /usr/tests
> 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 — 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?)
>> Those are user tunable too, but generally not tweaked, except when dealing with packages that use bsd.*.mk (e.g. ports):
>> # egrep --include \*.mk -r '^INCLUDEDIR|^LIBDIR' share/mk
>> share/mk/    /usr/lib
>> share/mk/        /usr/include
> 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’s 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’s 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’s better to write something simple from scratch for an initial port.


More information about the freebsd-testing mailing list