Question about build dependencies

[Tabitha McNerney]

Ryan,
A follow-up question if you don't mind (I had to walk away from the computer
to think and then come back to this). In the example you gave of:

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).

and:

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.
>

Let's say we have both gperf from Apple on the computer's root file system
at:

/usr/bin/gperf

Then as you said, having this available will satisfy the build dependency
condition of a port who has the gperf build dependency.

But what if we also decide to install the MacPorts version of gperf, as in:

/opt/local/bin/gperf

So in this case we have two instances of gperf. In this case, does MacPorts
always search the prefix (such as /opt/local/*) first before moving on to
the root file system? My intuition is that this is an obvious answer of
"yes" but I just wanted to confirm this (and as you said, this would apply
to not just build dependencies). For example, it might be a good idea to try
and have as many dependencies for ports (whether build, run or library) be
based on other ports rather than what Apple provides on the root filesystem
because Apple can (and will) change their mind about things (which is fine
with me just as long as for most if not all dependencies I can use MacPorts
and not depend on Apple's frame of mind)!

Thanks again,

Tabitha

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/20080529/0c61c526/attachment.htm