<div dir="ltr">Thanks! Maybe this would have worked well had I been debugging a port? I ended up installing a second MacPorts in a different prefix (/opt/macports-test).<div><br></div><div>David</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 27, 2020 at 9:31 AM Joshua Root <<a href="mailto:jmr@macports.org">jmr@macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-6-28 00:23 , David Richmond wrote:<br>
> New here to hacking on MacPorts; please talk to me like I'm dumb. Can<br>
> anyone point me to a resource (or offer their own thoughts) on setting<br>
> up test environments for ports?<br>
> <br>
> The MacPorts Guide obviously describes setting up a local repository,<br>
> but if I am, say, chasing a bug down during build, what is the<br>
> best/easiest way to create a "clean" test environment? That is to say,<br>
> say I have successfully built port_foo on my machine, but now a user or<br>
> bug report says it's broken. (Perhaps a dependency is out of whack.) How<br>
> can I build port_foo from "scratch," as if no ports at all are<br>
> installed? (Without breaking my own, active macports tree, that is.)<br>
> <br>
> I could just rename the port in the Portfile in my local repository, but<br>
> macports will find my local installed dependencies and it seems to me I<br>
> want a "clean" environment where it won't.<br>
> <br>
> And please do redirect me to a different approach altogether if I am<br>
> barking up the wrong tree.<br>
<br>
You can use trace mode (-t option) to hide any ports that are not<br>
declared as dependencies of the port being built. There are other<br>
possible approaches like installing in a different prefix or temporarily<br>
deactivating everything, but trace mode is the easiest and works well in<br>
most cases, the main drawback being reduced performance.<br>
<br>
- Josh<br>
</blockquote></div>