Best practices for port testing environment?

[David Richmond]

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 <jmr at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200703/65ab2abf/attachment.htm>