Confusion over BSD.tests.dist

Julio Merino julio at
Mon Nov 25 01:40:05 UTC 2013

On Sun, Nov 24, 2013 at 5:39 PM, Garrett Cooper <yaneurabeya at> wrote:
> 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.

Right... so that's the use case I was looking for: organization that
"cannot" change existing infrastructure to match the /usr/tests path.
I don't know the details of your previous company at all, but I'm
wondering if the path is the only thing that matters or it's just one
tiny detail among many?

I understand the use case... so the question is: is it worth
supporting it (going all the way through to support this and other
customizations that such scheme may require)?  (Personally I tend to
think it's not, but I don't have a strong opinion as long as the
proposed modifications are simple enough.)

Julio Merino / @jmmv

More information about the freebsd-testing mailing list