Question about build dependencies

Tabitha McNerney tabithamc at gmail.com
Thu May 29 02:05:29 PDT 2008


Ryan and friends,
I really love the MacPorts community. Really, I mean that. It's one of the
most enjoyable groups of people even though we have never met in person and
even though we each contribute in different ways. Thank you to everyone for
the various contributions and for making MacPorts way way cool!

Thanks as always,

Tabitha

On Wed, May 28, 2008 at 7:38 PM, Ryan Schmidt <ryandesign at macports.org>
wrote:

> I know the feeling. We can't always be experts at everything! There's too
> much to know. Anytime you have MacPorts questions, you know where to ask!
> (Right here. You ask here.)
>
>
>
> On May 29, 2008, at 00:01, Tabitha McNerney wrote:
>
>  Ok, I am learning ever more, thank you for yet even more clarification.
>> Therefore the user's shell PATH variable really doesn't matter.
>>
>> Thank you yet again (I am realizing that this is really kind of obvious if
>> one takes a harder look at the MacPorts files themselves -- its a challenge
>> at times as a sys admin since my head has to be in may clouds and juggling a
>> variety of systems including but not limited to MacPorts).
>>
>> T.M.
>>
>> On Wed, May 28, 2008 at 6:58 PM, Ryan Schmidt <ryandesign at macports.org>
>> wrote:
>> Well, it doesn't depend on the user's PATH. MacPorts internally sets the
>> PATH to a very specific value which includes the OS directories and the
>> MacPorts prefix. And it searches those paths only.
>>
>> Also, this is not specific to the depends_build section. Any dependency
>> (build, library or runtime) can be written in this way.
>>
>>
>>
>> On May 28, 2008, at 23:53, Tabitha McNerney wrote:
>>
>> Ah, thanks, that makes sense -- in other words, if there is a build
>> depends that can already be satisfied by a build that the operating system
>> (e.g., Mac OS X) provides, then it will go ahead and use that without
>> complaining if, at the same time, a MacPorts-supplied build is not available
>> (e.g., it all depends on if the binary is in the PATH).
>>
>> Thanks Ryan for help in understanding this!
>>
>> Best,
>>
>> T.M.
>>
>> On Wed, May 28, 2008 at 6:43 PM, Ryan Schmidt <ryandesign at macports.org>
>> wrote:
>> On May 28, 2008, at 22:38, Tabitha McNerney wrote:
>>
>> I have what might seem to be a dumb question. I noticed today that the
>> MacPort named "libiconv" version 1.12 has a build dependency on another port
>> named gperf, specifically:
>>
>> $ port deps libiconv
>> libiconv has build dependencies on:
>>      gperf
>>
>> What I find very interesting about this situation, however, is that on my
>> MacPorts system I have not consciously built / installed the gperf port. But
>> I have successfully built and installed the libiconv port. Therefore, I am
>> wondering, how is it possible that the libiconv port was able to build and
>> install without the gperf port dependency having first been built?
>>
>> Apparently libiconv requires gperf. I don't know anything about this;
>> that's the way the port was when I inherited it.
>>
>> The dependency is declared like this:
>>
>> depends_build \
>>      bin:gperf:gperf
>>
>> That means if a binary (the "bin" part) called "gperf" (the first "gperf"
>> part) does not exist on the computer, then install the gperf port (the 2nd
>> "gperf" part).
>>
>> On my Tiger system, a gperf binary is provided by Mac OS X in
>> /usr/bin/gperf so the gperf port does not need to be installed.
>>
>> Usually ports depend on other ports only. In this case, the previous
>> maintainer of libiconv must've thought the gperf provided by Mac OS X was
>> sufficient. I don't even know what gperf does.
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-users/attachments/20080528/9b1da464/attachment.htm 


More information about the macports-users mailing list