Question about build dependencies
Tabitha McNerney
tabithamc at gmail.com
Wed May 28 22:01:11 PDT 2008
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/1cba861a/attachment.htm
More information about the macports-users
mailing list