Page MenuHomeFreeBSD

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

Authored by ngie on Feb 20 2019, 2:34 AM.

Details

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

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

ngie retitled this revision from Import capsicum-test into ^/vendor/google/capsicum-test to Import capsicum-test into ^/vendor/google/capsicum-test/dist.Feb 20 2019, 2:35 AM
ngie removed reviewers: rwatson, manpages.
ngie edited subscribers, added: capsicum; removed: jonathan.

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

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.

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

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?

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.

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

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.

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

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.

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.

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.

Omit subdirs

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

This revision is now accepted and ready to land.Mar 12 2019, 1:20 AM
This revision was automatically updated to reflect the committed changes.