On 31 May 2018 at 19:45, Ryan Schmidt <ryandes...@macports.org> wrote: > > On May 31, 2018, at 21:42, Eitan Adler wrote: >> On 31 May 2018 at 19:40, Ryan Schmidt wrote: >>> Or: A setting in macports.conf that makes MacPorts base add -g for all >>> ports? That would cause the built result to be different. We could offer >>> that, but would have to also make sure that MacPorts doesn't attempt to >>> download any binaries from our packages servers, since they would not have >>> been built with that setting. >> >> This one. Personally I'd be fine with "best effort" and fallback to >> packages, but I imagine some would not be. > > That's not how MacPorts works. > > When you ask MacPorts to install a port, it tries to get a binary package. If > that fails, it tries to build from source. > > If we introduce a new macports.conf setting that lets you enable debug > symbols, and that setting is not on by default, then that setting will not be > on on our buildbot workers which produce the binary packages. So if you get a > binary package, you will not get debug symbols, even if that setting is on on > your system. You will only get debug symbols if the port, for whatever > reason, builds from source on your system. That would be confusing. > Therefore, so that you get consistent behavior, if we introduce such a new > setting, it must also prevent all use of binary packages.
I understand, and that's besides the point for now. Would we be generally okay with adding a new option to add -g globally? Perhaps include_debug_symbols true. This ought to have three effects (a) include -g (b) exclude strip(1) (c) port specific changes at their option this ought not to change optimization or related. -- Eitan Adler
