Import capsicum-test into ^/vendor/google/capsicum-test/dist

[ngie]

Summary

The following change imports google/capsicum-test@9333154 from GitHub.

This test suite helps verify capsicum(3) support via functional tests
written in the GoogleTest test framework.

Kernel support for capsicum(4) is tested by side-effect of testing
capsicum(3).

NB: as discussed in a previous [closed] PR [1], the casper(3) tests are
incomplete/buggy and will not pass on FreeBSD. Thus, I have no intention of
integrating them into the build/test on FreeBSD as-is.

The import command used was:

curl -L https://github.com/google/capsicum-test/tarball/9333154 | tar --strip-components=1 -xvzf - -C dist/
rm -Rf dist/*/

1. https://github.com/google/capsicum-test/pull/26

Test Plan

n/a

[emaste]

Are we going to update this to use newer GoogleTest first?

[ngie]

In D19261#415228, @emaste wrote:

Are we going to update this to use newer GoogleTest first?

The version of capsicum-test in this commit I'm targeting has googletest 1.8.1, which is the most recent release.

[emaste]

But there's a gtest-1.6.0 included here as well?

[drysdale_google.com]

As per the discussion at https://github.com/google/capsicum-test/pull/26, there's some things that maybe needn't get imported here:

• Anything under ./casper/ (which includes the gtest-1.6.0 copy), because FreeBSD is already the up-to-date source-of-truth for Casper related code
• Anything under ./libcaprights/, because it's entirely Linux-specific.

(Also: is there a pre-existing version of gtest-1.8.1 that could make the version here superfluous?)

However, I'm merely a kibitzer -- maybe there's a policy/tool constraint that requires reproducing the entire repo?

[emaste]

In D19261#415418, @drysdale_google.com wrote:

However, I'm merely a kibitzer -- maybe there's a policy/tool constraint that requires reproducing the entire repo?

We have examples of both approaches - importing stripped-down copies of the repo, or the entire, unmodified repo. IMO if there's a only small fraction of upstream that we don't need and could remove it's not worth it, but if we need less than half (say) then it makes sense to me to strip it down.

Right now Phab says we'd bring in 633 files, while AFAICT we really only need around 27 .{c,cc,h} files in the top level capsicum-test directory.

[brooks]

In D19261#415424, @emaste wrote:

In D19261#415418, @drysdale_google.com wrote:

However, I'm merely a kibitzer -- maybe there's a policy/tool constraint that requires reproducing the entire repo?

We have examples of both approaches - importing stripped-down copies of the repo, or the entire, unmodified repo. IMO if there's a only small fraction of upstream that we don't need and could remove it's not worth it, but if we need less than half (say) then it makes sense to me to strip it down.

Right now Phab says we'd bring in 633 files, while AFAICT we really only need around 27 .{c,cc,h} files in the top level capsicum-test directory.

Since google test is GPL it would be nice if it wasn't imported. (EDIT: imported here, specifically, the general import is fine.)

[brooks]

In D19261#415435, @brooks wrote:

In D19261#415424, @emaste wrote:

In D19261#415418, @drysdale_google.com wrote:

However, I'm merely a kibitzer -- maybe there's a policy/tool constraint that requires reproducing the entire repo?

We have examples of both approaches - importing stripped-down copies of the repo, or the entire, unmodified repo. IMO if there's a only small fraction of upstream that we don't need and could remove it's not worth it, but if we need less than half (say) then it makes sense to me to strip it down.

Right now Phab says we'd bring in 633 files, while AFAICT we really only need around 27 .{c,cc,h} files in the top level capsicum-test directory.

Since google test is GPL it would be nice if it wasn't imported. (EDIT: imported here, specifically, the general import is fine.)

Ah, it just the auto tools just that has GPL bits in it. That said, this import looks like one to trim. Removing core from the review.

[ngie]

@emaste: For clarity, I am planning on following @drysdale_google.com's suggestion by importing all directories from GitHub into the vendor branch, but will pruning the unnecessary directories when importing the tests into contrib/. I didn't plan on ever importing the googletest directories, but instead rely on the work I started in rS344081 with integrating googletest into the tree.
@brooks: Yeah... googletest relies on autoconf macros as one of its 3 supported build systems: autotools, bazel, and cmake.

[emaste]

In D19261#415452, @ngie wrote:

@emaste: For clarity, I am planning on following @drysdale_google.com's suggestion by importing all directories from GitHub into the vendor branch, but will pruning the unnecessary directories when importing the tests into contrib/. I didn't plan on ever importing the googletest directories, but instead rely on the work I started in rS344081 with integrating googletest into the tree.

Fair enough, I think there's no significant overhead from importing into vendor/ - it won't affect any regular checkouts or the git mirror.

[emaste]

based on some further discussion on IRC suggestion is to just skip importing all of the subdirectories, even into vendor/.
We are unlikely to ever need them, and it's unlikely that there will be significant upstream development in the future anyhow.

[ngie]

In D19261#416809, @emaste wrote:

based on some further discussion on IRC suggestion is to just skip importing all of the subdirectories, even into vendor/.
We are unlikely to ever need them, and it's unlikely that there will be significant upstream development in the future anyhow.

Ok.

[ngie]

Omit subdirs

Upstream should be adjusted to pull down these dependencies using cmake or
require them to be preinstalled first.