<div dir="ltr">In addition to the code Ken just provided, he and others have helped me with some test-related "protection" code, so that in addition to a +tests variant, there is the following section of code (I usually place it after any build-related sections, and before any destroot-related sections, in order to keep my portfiles laid out in the same order as the port phases):<div><br></div><div>pre-test {</div><div>    if {![variant_isset tests]} {</div><div>        ui_error "'tests' variant must be activated to enable test support"</div><div>        error "Please enable the 'tests' variant and try again"</div><div>    }</div><div>}</div><div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- </div><div>Jason Liu</div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 28, 2021 at 11:13 AM Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com">ken.cunningham.webuse@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
On 2021-09-28 7:44 a.m., Daniel J. Luke wrote:<br>
> On Sep 20, 2021, at 10:20 AM, Daniel J. Luke <<a href="mailto:dluke@geeklair.net" target="_blank">dluke@geeklair.net</a>> wrote:<br>
>> On Sep 20, 2021, at 8:15 AM, Frank Dean <<a href="mailto:frank@fdsd.co.uk" target="_blank">frank@fdsd.co.uk</a>> wrote:<br>
>>> Daniel J. Luke <<a href="mailto:dluke@geeklair.net" target="_blank">dluke@geeklair.net</a>> writes:<br>
>>>> The newest version of clamav uses cmake for builds. In the 'configure' stage, I have it disabling tests because otherwise it won't build without the test dependencies installed (check and pytest).<br>
>>>><br>
>>>> Do we have a template or example of a canonical way to handle this? I don't see an obvious hook for when someone is running `port test` to change configure.args (I could, of course, add a post-extract/pre-configure and do some non-declaritive test to see if `port test` is being run and use that to branch - but that feels like a bad design choice).<br>
>>> The rapidjson port implements a 'tests' variant to handle a similar<br>
>>> situation.  I used the same pattern for the libosmium port.  The tests<br>
>>> can then be run with `sudo port -d test current +tests`.<br>
>> That works, I guess.<br>
>><br>
>> Is there interest in having base auto-add +tests if `port test` is called? (I haven't looked at base/ code in a while, but it seems possible). I like to imagine a future where we have enough infrastructure that we would run `port test` for any ports that have test.run set.<br>
> On this same train of thought - clamav tests run against the installed libraries (like some other ports tend to do) - in long-ago times I'd solve this by setting DYLD_LIBRARY_PATH - but since SIP started removing these that no longer works normally. I think trace mode has a(n elaborate) workaround where it copies binaries and executes the copies, but that doesn't seem like something I should implement in a portfile ;-) [This is another instance where if trace mode were the default, things would 'just work']<br>
><br>
> Has anyone else already solved this?<br>
<br>
<br>
The way our cmake PortGroup sets things up, running tests is harder. You <br>
can configure cmake to allow testing to find the libraries in the build <br>
tree. See for example what I did in libcbor:<br>
<br>
<br>
variant tests description {enable tests} {<br>
     depends_test-append         port:cmocka<br>
     configure.args-append       -DWITH_TESTS=ON<br>
     configure.pre_args-replace -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON \<br>
-DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=OFF<br>
     test.run            yes<br>
     test.target         test<br>
}<br>
<br>
Ken<br>
<br>
<br>
<br>
<br>
<br>
<br>
><br>
</blockquote></div>