[127391] trunk/dports/kde

Ian Wadham iandw.au at gmail.com
Sun Oct 26 19:03:14 PDT 2014

Hi Ryan,

On 27/10/2014, at 12:10 PM, Ryan Schmidt wrote:
> On Oct 26, 2014, at 7:10 PM, Marko Käning wrote:
>> Ryan, any suggestions?
> My suggestions are:
> We try to avoid variant names beginning with "no". We try to use variant names that
> mention enabling something, rather than names that mention disabling something.

No problem with that… :-)

> When there is a variant that aids in debugging a program, it is typically named "debug".

With all due respect, Ryan (and my respect for you is very great), please not this hoary
old chestnut… :-)

Variants in MacPorts are global in scope, which means that variants like "debug" and
also "docs" get applied to *every* dependency, back as far as Sumerian clay tablets… :-)
With KDE and Qt having such a long list of dependencies, well…

If I ask for "debug" I get a huge build and vastly more code-symbols and line-numbers
than I really want for debugging at the top of the dependency tree.  Hence René's idea
of "nostrip", which merely sets the linker not to throw away (strip) the symbols in the KDE
part of the build.

With "docs", I get docs OK, but again with a huge build and vastly more documentation
tools than I will ever use (e.g. the whole of TeX and several language translations), whereas
KDE only requires you to run meinproc4, which is part of KDE (but thereby hangs another tale…).

> If the existing debug variant in the portgroup is not useful, perhaps we need to reconsider that variant.


I have canvassed that once or twice on this list and there has been useful and
informed discussion, but so far no action… :-(

I think all this needs is to make "debug" and "docs" exceptional variants in MacPorts, in
that they are treated as applying only to the currently requested port and not to all of its

Maybe, too, "+docs" should be the default for top-level ports, but not for all the libraries
and utilities they depend upon --- if we can separate the sheep from the goats… :-)

All the best, Ian W.

More information about the macports-dev mailing list