Let's talk about +debug

[Sean Farley]

> http://lists.macosforge.org/pipermail/macports-users/2012-April/028301.html
> ... continues at: http://lists.macosforge.org/pipermail/macports-users/2012-April/028322.html
>
> I take even one person bringing this up on macports-user as an indicator that there's a bigger need than I would have thought for there to be an easier way to make builds with debug output and symbols.
>
> That said I don't think the answer is a default debug variant in base. A base variant for something that only really is useful for a subset of ports and is bound to fail spectacularly in some cases and subtly in others feels a bit like false advertising. Should we ask maintainers to test with the debug variant as well? They're the ones who will get tickets when there is something wrong with `install <port> +debug`.
>
> Consider the user/developer in the macports-users discussion above, if we had the patch in base for a default debug variant and told him to try that, would he have gotten what he wanted?
>
> For my own workflow where I depend on ports as a developer I usually have those in a local repository to lock down the version and whatever modifications to the port that I need. Doesn't feel unreasonable to maintain that myself for something I integrate that deeply with.

>From the other thread: "My perception is that mostly debug builds are
to help with the development of the libraries themselves?" There is
more to it than that. Code that I write which is built on top of any
library built with macports might need to follow a branch into the
library, or watch a variable that happens to be set by said library,
etc.