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).
David On Sat, Jun 27, 2020 at 9:31 AM Joshua Root <j...@macports.org> wrote: > On 2020-6-28 00:23 , David Richmond wrote: > > New here to hacking on MacPorts; please talk to me like I'm dumb. Can > > anyone point me to a resource (or offer their own thoughts) on setting > > up test environments for ports? > > > > The MacPorts Guide obviously describes setting up a local repository, > > but if I am, say, chasing a bug down during build, what is the > > best/easiest way to create a "clean" test environment? That is to say, > > say I have successfully built port_foo on my machine, but now a user or > > bug report says it's broken. (Perhaps a dependency is out of whack.) How > > can I build port_foo from "scratch," as if no ports at all are > > installed? (Without breaking my own, active macports tree, that is.) > > > > I could just rename the port in the Portfile in my local repository, but > > macports will find my local installed dependencies and it seems to me I > > want a "clean" environment where it won't. > > > > And please do redirect me to a different approach altogether if I am > > barking up the wrong tree. > > You can use trace mode (-t option) to hide any ports that are not > declared as dependencies of the port being built. There are other > possible approaches like installing in a different prefix or temporarily > deactivating everything, but trace mode is the easiest and works well in > most cases, the main drawback being reduced performance. > > - Josh >