Question about build dependencies

[Ryan Schmidt]

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.