depends_run vs depends_lib (was Re: cctools)

Joshua Root jmr at
Sat Jan 17 15:53:04 PST 2015

License checking. I meant license checking, not arch checking.

On 2015-1-18 10:46 , Joshua Root wrote:
> Arch checking is not done for runtime deps, and they are not installed
> if you just run e.g. the configure or build target.
> - Josh
> On 2015-1-18 03:33 , Jeremy Huddleston Sequoia wrote:
>> This should not be the main difference between depends_lib and depends_run as I see it.  The main difference between those should be architecture.
>> If I depends_run on port:bzip2, I just care that the bzip2 executable be present, and I can run it.  I don't care what architectures it has.
>> If I depends_lib on port:bzip2, I intend to link against libbz2 and need to make sure that the installed architectures match the build architectures.
>> Thus ports only in depends_run should be in depends_skip_archcheck.  Whether that is implemented yet or not, I'm not certain, but that is the intention.
>> --Jeremy
>>> On Jan 17, 2015, at 06:47, Jeremy Lavergne <jeremy at> wrote:
>>> Thanks for clarifying the difference, Clemens.
>>>>> Looks like the bug is in portutil.tcl.  depends_run should be included
>>>>> as a dependency of build.  I'll just change it to a _lib dependency.
>>>> If we do that, that would remove the last difference between depends_lib
>>>> and depends_run. I was under the impression that this difference was why
>>>> we even had both depends_run and depends_lib. As you might know, we do not
>>>> currently depend on depends_lib only containing libraries (and IMO that
>>>> doesn't make sense because we could easily figure out dynamic library
>>>> dependencies using a couple of lines of code automatically, and static
>>>> library dependencies are usually not even listed in depends_lib, but
>>>> depends_build).
>>> I vaguely remember a discussion on the list about the semantics of our
>>> dependencies. I'll try to get it going again.
> _______________________________________________
> macports-dev mailing list
> macports-dev at

More information about the macports-dev mailing list