I think this is good to land now and we can do further improvements in the later phases.

Submit my current review drafts, I have to change computer this weekend and I believe I can finish (and accept) this weekend.

Please also check bug 278011 with the maintainer. Thanks!

It would be good if the patch can contain more context for the lines before/after, by using arc tool or see https://wiki.freebsd.org/Phabricator#Create_a_Revision_via_Web_Interface

In D44257#1010727, @mizhka wrote:

@lwhsu , now all tests are passed, portlint & portclippy are happy. If no objectives, I would like to commit it

Don't forget to update .Dd when content of manual page changed. :-)

Initial version has been submitted by Teodor Sigaev (maintainer of cad/PrusaSlicer).

Just be curious, should this be directly submitted to https://github.com/llvm/llvm-project/ ?

Oh yes thanks for reminding, this is indeed the better solution.

In D44010#1004129, @jamie wrote:

I'll admit very little familiarity with the testing framework. If there's a standard to show a test as skipped that doesn't indicate a problem, that sounds best. But if it just claims that it's passed, it would seem better to just not run it. Though both is probably a good idea: still have it pass (like if the test was built at another time), but don't build it on a jail-less system.

I don't really object this approach, but I don't really support it either. Do you think it's okay to let the test case check if jail utility exists, and skip running if no?

In D37973#1003520, @bz wrote:

@lwhsu I'll just pick the first review given they all live in a window here; last time I checked and asked if they were ready for review I was told to hold off for further changes? Have they been addressed, as in, is the stack of wtap changes ready for review?

In D43786#1000229, @bofh wrote:

In D43786#1000186, @markj wrote:

I wonder if using make(1) is really a good choice for this. Doing things like computing the RAM size of the VM in make feels awkward. There's also no good way to see what parameters are available to developers, and the framework is not friendly to user error (e.g., misspelling a variable name on the command line means that make will silently do the wrong thing). There is no namespacing for parameters (parameters for the build, VM boot, and the test itself are all mixed together).

make is definitely not the best tool but this is what was discussed by many when we initially planned this work.

To committers: if you want to commit this before me find time on this, please don't forget asking clusteradm/wwwadm to create where/ -> download/ redirection first!