Question regarding +debug variant of KDE ports and qt4-mac

Ian Wadham iandw.au at gmail.com
Sun Jun 29 20:46:32 PDT 2014


On 29/06/2014, at 7:52 PM, Marko Käning wrote:
> on the kde-mac ML the question came up whether the necessity to install qt4-mac in its
> debug variant - when one simply needs KDE ports installed in their debug variant - is only
> due to MacPorts' way of handling port variants...
> 
> If that's indeed the case, it may seem to be a good idea to replace in all KDE software
> ports the debug variant by a new variant - perhaps called debug_kde. In that case all
> ports depending on kdelibs4 would nicely manage their debug_kde variants amongst
> themselves and not mess with the standard-MacPorts debug variant at all anymore.
> 
> The debug output of qt4-mac is very verbose and of no much use when debugging crashing
> KDE applications anyways. Also one would not be forced to install "qt4-mac +debug" from
> source and only be left with locally rebuilding the much smaller KDE ports.
> 
> What do you think?

++1 from me!!!

I would also like us to consider something similar for +docs, especially with KDE.

That would avoid pulling in all the other text-processing dependencies of other ports, such
as the doxygen/texlive/latex chain, while leaving the user to take his or her own chances
with meinproc4 (it never fails for me).

Also a +docs_kde would not have to be a different binary package - just a downloading
and "compiling" of docs subdirectories with meinproc4, which will be already installed.

Come to think of it, I don't think debug or docs in one port is usually dependent on any
other port, except for the tools used to format documents, so perhaps MacPorts could
have --debug and --docs options for port install, which would apply to the ports that
were being "requested" on that installation run and on upgrades of same.

Something like that would give every user fine control over what ports to debug or
document, but maybe it is not so easy to implement (?).

Cheers, Ian W.



More information about the macports-dev mailing list