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.

_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to