Re: Question regarding +debug variant of KDE ports and qt4-mac
You only need a stub if you’re renaming/replacing a variant to chain the requirement: it doesn’t really matter if it’s going away unless there is an active_variant dependent, in which case simply fix that first and wait two weeks. On Jul 1, 2014, at 2:48, Marko Käning wrote: > The question is whether variants in general can be added temporally in order > to get rid of > them once we've got MacPort changed according to Michael's proposal wrt > +debug? > > Is it actually allowed to remove a port variant just like that or does it > require to leave > some stub around in such a case? I hope we've got that documented somewhere > in the wiki, > Guide or man pages? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Question regarding +debug variant of KDE ports and qt4-mac
Hi all,
> At the risk of variant bloat we could also s/replace/add/ +debug_${name} and
> +docs_${name}.
The question is whether variants in general can be added temporally in order to
get rid of
them once we've got MacPort changed according to Michael's proposal wrt +debug?
Is it actually allowed to remove a port variant just like that or does it
require to leave
some stub around in such a case? I hope we've got that documented somewhere in
the wiki,
Guide or man pages?
Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Question regarding +debug variant of KDE ports and qt4-mac
Hi Michael, > Actually, I was going for the more general approach: Any port can have a > +debug option. ... > One can always use "enforce variants" to get as many dependencies as possible > using +debug. oh, I see, that would mean that the debug option would get a different handling than a normal variant with respect to propagation to dependent ports. That sounds like a plan to me! I hope this is not too hard to implement in port... > Basically: I'd prefer to not have a new variant just for KDE for > debugging purposes. I see where you're coming from. Well, it all depends on whether one can implement the new behaviour of +debug easily. And, thanks for the hint regarding qt[45]-mac coinstallability! That would indeed be amazing as we can expect to have the two around for quite a few years to come - as it happend with qt[34] as well as KDE[34]! Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Question regarding +debug variant of KDE ports and qt4-mac
On Jun 29, 2014, at 8:46 PM, Ian Wadham wrote:
> 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.
At the risk of variant bloat we could also s/replace/add/ +debug_${name} and
+docs_${name}.
Regards,
Bradley Giesbrecht (pixilla)
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Question regarding +debug variant of KDE ports and qt4-mac
On Mon, Jun 30, 2014, at 03:36 AM, Marko Käning wrote:
> > If done correctly, one can "enforce variants" to get +debug everywhere
> > possible. Or, just for the ports needed. Since +debug is generally not
> > the default, this would help speed up those installs using +debug which
> > would be compiled from source locally.
>
> I figure you're talking in general here, i.e. it would be the to be newly
> introduced variant debug_kde which you're talking about, right?
Actually, I was going for the more general approach: Any port can have a
+debug option. In order to debug a specific port, we sometimes need all
dependencies to include the +debug option as well as keep the build
around; though, sometimes we can get away with a smaller subset of
dependency ports using the +debug option. So, go ahead and +debug as
before; this allows the user the ability to select which ports are
+debug and which are not. One can always use "enforce variants" to get
as many dependencies as possible using +debug.
Basically: I'd prefer to not have a new variant just for KDE for
debugging purposes. I don't see that as a necessity. I think it's wiser
to keep within the current MO of MacPorts for +debug. That said, I'm not
longer helping with KDE; so, if you feel (and the MP top-devs agree)
that this would make sense, then go for it!
> Anyway, it is awesome to see qt5-mac appearing on the scene!!!
> I am looking forward to learn from its setup for the KDE/CI system which
> I am currently working on [1].
> Thanks so much for bringing qt5 now MacPorts'ish to OSX!!!
Yes, yes it is. I give full credit to mcalhoun!
> Re qt5-mac I am wondering whether coinstallability with qt4-mac will be
> achieved at some point, as it was already discussed in the related ticket
> [2]. I'll post my question comment there.
My recommendation is to move the Qt ports to qt_dir ==
"${prefix}/libexec/${name}/". This way we force any project using them
to use a specific version, no defaults provided. This might cause
headaches for a few ports, but I'll guess very few ports since most use
qmake -- which is designed to work very well in any install location. -
MLD
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Question regarding +debug variant of KDE ports and qt4-mac
Hi Ian, > I would also like us to consider something similar for +docs, especially with > KDE. > 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. yes, that sounds very good. This helps us avoiding the meinproc4 issues met every now and then. > 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. Well, that would be quite a change to port. Wondering what the macports devs will say. Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Question regarding +debug variant of KDE ports and qt4-mac
Hi Michael, > I like this as a general idea, because it is often useful to debug some > subset of a group of ports, maybe all of the dependent ports, and maybe > just the primary port in question. yep. > If done correctly, one can "enforce variants" to get +debug everywhere > possible. Or, just for the ports needed. Since +debug is generally not > the default, this would help speed up those installs using +debug which > would be compiled from source locally. I figure you're talking in general here, i.e. it would be the to be newly introduced variant debug_kde which you're talking about, right? > qt4-mac (and, now qt5-mac), are notorious for being enormous > time consuming compiles, for which having a pre-compiled binary for > "most users" is a big win. That's the idea. :) > Anyway, I hope I interpreted your proposal correctly, Marko. - MLD Well, I hope I did interprete your response correctly, Michael. ;) Anyway, it is awesome to see qt5-mac appearing on the scene!!! I am looking forward to learn from its setup for the KDE/CI system which I am currently working on [1]. Re qt5-mac I am wondering whether coinstallability with qt4-mac will be achieved at some point, as it was already discussed in the related ticket [2]. I'll post my question comment there. Thanks so much for bringing qt5 now MacPorts'ish to OSX!!! Greets, Marko [1] https://trac.macports.org/wiki/KDEProblems/KDEMacPortsCI [2] http://trac.macports.org/ticket/37331 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Question regarding +debug variant of KDE ports and qt4-mac
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 macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Question regarding +debug variant of KDE ports and qt4-mac
I like this as a general idea, because it is often useful to debug some subset of a group of ports, maybe all of the dependent ports, and maybe just the primary port in question. If done correctly, one can "enforce variants" to get +debug everywhere possible. Or, just for the ports needed. Since +debug is generally not the default, this would help speed up those installs using +debug which would be compiled from source locally. qt4-mac (and, now qt5-mac), are notorious for being enormous time consuming compiles, for which having a pre-compiled binary for "most users" is a big win. Anyway, I hope I interpreted your proposal correctly, Marko. - MLD On Sun, Jun 29, 2014, at 05:52 AM, 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? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Question regarding +debug variant of KDE ports and qt4-mac
Hi Qt4-affine devs, 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? Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
