Plugging ATF tests into the build and other cleanups
Julio Merino
julio at meroh.net
Wed Oct 30 02:48:45 UTC 2013
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 <sjg at juniper.net> 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
More information about the freebsd-testing
mailing list