Plugging ATF tests into the build and other cleanups

[Garrett Cooper]

On Oct 27, 2013, at 6:31 PM, Julio Merino <julio at meroh.net> wrote:

> On Sun, Oct 27, 2013 at 8:25 PM, Eitan Adler <lists at eitanadler.com> wrote:
>> On Sun, Oct 27, 2013 at 6:12 PM, Julio Merino <julio at meroh.net> 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?

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?
> 
> 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.

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