Let's talk about +debug
Daniel J. Luke
dluke at geeklair.net
Thu Apr 19 13:28:53 PDT 2012
On Apr 19, 2012, at 4:14 PM, Daniel Ericsson wrote:
> 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`.
exactly.
Historically we've told people who want debug info to either do what you do (local repository) or that macports isn't really in the business of solving that particular problem.
> 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.
I agree, hence my suggestion that the patch be added instead as a portgroup (the portgroup being an easy way to let ports opt-in to that functionality). Maintainers can add the portgroup if it works for their port. End users can edit the port (or make their own local repo) more easily since there's a canned recipe that mostly works.
That way, we also don't have to consider all of the secondary effects (perl/python/apr/other software storing the compiler & flags used to build them and passing them down to other modules that may or may not be being built with +debug, etc.)
--
Daniel J. Luke
+========================================================+
| *---------------- dluke at geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+
More information about the macports-dev
mailing list