qt4-mac dependencies

Ryan Schmidt ryandesign at macports.org
Thu Jul 8 11:45:18 PDT 2010


On Jul 8, 2010, at 12:52, Michael Dickens wrote:
> On Thu, 08 Jul 2010 12:56 -0400, Jeremy Lavergne wrote:
>> Qt4-mac (and likely the other flavors) does not mark qt4_select as a
>> dependency after the build phase.
>> 
>> That is, if you
>> 1: sudo port destroot qt4-mac
>> 2: sudo port uninstall qt4_select
>> 3: sudo port install qt4-mac
>> you'll error out from a missing qt4_select.
> 
> Hadn't thought of that, but it would certainly be an issue.
> 
>> I would suggest using depends_run instead or in addition to. Any other
>> ideas?
> 
> The 'qt4-*' Ports currently or will soon require 'qt4_select' for
> "post-activate" and "pre-deactivate". So, 'qt4_select' needs to be
> specified somehow as a dependency.  Whatever dependency type is correct
> for those two stages is what I need to specify: if just "depends_run"
> then I'll do that, but if others then those as well.  I'm not familiar
> with which stages correspond to which "depends", so I'm open to
> suggestions.

depends_build means "needed at build time (i.e. during the configure, build, or destroot phases) but not needed at runtime (i.e. after the installation is finished and when the user is using the software)".

depends_run means "needed at runtime but not needed at build time".

depends_lib means "needed at both build time and runtime".

From MacPorts' perspective I don't think there's a big difference between depends_lib and depends_run; in either case, MacPorts must prevent the uninstallation of a dependency so that the software can still function.

I would say depends_lib is probably the best qt4_select dependency type for qt4-mac.


> All of that said, the last time I tried adding "depends_FOO" and doing
> what you did (ticket #25475), 'port' (latest from SVN) didn't honor
> those dependencies -- so, this functionality doesn't seem to be
> currently built-in to 'port' or it is not functioning as desired: is it
> a planned feature for the future of 'port'?

This functionality has existed in MacPorts for years, certainly since I have been involved with the project, probably since the beginning, and should work as intended.

cmake needs its dependencies declared as library dependencies, not build dependencies. I'll update the ticket.


> I'm all for these changes; it's just a matter of having enough info to
> know how to do the implementation. - MLD





More information about the macports-dev mailing list