Question about build dependencies

[Ryan Schmidt]

On May 29, 2008, at 07:43, Tabitha McNerney wrote:

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

In the function mportinit in the file base/src/macports1.0/ 
macports.tcl on line 590 it says:

     if {![info exists binpath]} {
         set env(PATH) "${prefix}/bin:${prefix}/sbin:/bin:/sbin:/usr/ 
bin:/usr/sbin:${x11prefix}/bin"
     } else {
         set env(PATH) "$binpath"
     }

So it puts ${prefix}/bin in the path before the other binary  
directories. So if you have the gperf port installed, libiconv will  
use the MacPorts version of gperf. Otherwise it will use the Mac OS X  
version of gperf.

Unless you've overridden this path by setting binpath in the  
macports.conf. (This is only available in MacPorts trunk, not in  
MacPorts 1.6.0.)

For libraries, I'm not sure where the code is that searches, or what  
order it searches in. I would hope it's the same though -- MacPorts  
prefix first, then the rest.


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

Which is precisely why the MacPorts project recommends that ports  
depend on other ports, not on binaries or libraries that may be  
installed on the system by Apple, whose versions or features could  
change under our noses by a system update.

http://trac.macports.org/wiki/FAQ#WhyisMacPortsusingitsownlibraries

I'm not sure why the libiconv port was written differently here.  
Looks like Mac OS X 10.4 provides gperf 3.0.1. MacPorts provides  
gperf 3.0.3. Maybe I should change the port to use the gperf port  
exclusively. It would be more consistent with our policy.