[29735] trunk/dports/x11/gtk-engines2/Portfile

[Ryan Schmidt]

On Oct 8, 2007, at 16:02, Juan Manuel Palacios wrote:

> On Oct 8, 2007, at 3:57 PM, Ryan Schmidt wrote:
>
>> On Oct 8, 2007, at 14:49, Yves de Champlain wrote:
>>
>>> Le 07-10-08 à 14:45, N_Ox a écrit :
>>>
>>>> Le 8 oct. 07 à 16:44, Yves de Champlain a écrit :
>>>>
>>>>> Le 07-10-08 à 05:34, source_changes at macosforge.org a écrit :
>>>>>
>>>>>> Revision 29735 Author rhwood at macports.org Date 2007-10-08  
>>>>>> 02:34:33 -0700 (Mon, 08 Oct 2007) Log MessageUpdate  
>>>>>> dependencies based on trace output-depends_build	port:p5-xml- 
>>>>>> parser
>>>>>> -depends_lib	port:gtk2 +depends_build	\ +	port:expat \ +	 
>>>>>> port:p5-xml-parser \ +	port:perl5.8 +depends_lib	\ +	port:atk  
>>>>>> \ +	port:cairo \ +	port:fontconfig \ +	port:freetype \ +	 
>>>>>> port:gettext \ +	port:glib2 \ +	port:gtk2 \ +	port:jpeg \ +	 
>>>>>> port:libiconv \ +	port:libpng \ +	port:pango \ +	port:tiff
>>>>>
>>>>> Sorry, but does this make any sense at all ?
>>>>> I think all it will do is make the dependency checking phase  
>>>>> even longer and the Portfile stuffier.
>>>>> And what about the gnome port ?
>>>>
>>>> It does make sense if all of these are hard dependencies (as in  
>>>> "hardcoded in configure.in or somewhere else.")
>>>> We should not do "If A depends on B and C and B depends on C,  
>>>> then let's say A depends on B only."
>>>
>>> Why not ?
>>
>> If, as in nox's hypothetical example, A really does depend on B  
>> and C, then both B and C should be listed as dependencies of A. C  
>> should not be excluded from the dependencies of A just because B  
>> currently depends on C. B might stop depending on C at some point,  
>> at which point A would break if A really does itself independently  
>> need C.
>
> But if A only depends on C through B's dependency on it, I don't  
> really see why such link should be listed explicitly in A's  
> dependency list.

I agree with that also.

> As in the gtk-engines2 example above: does such port really itself  
> *explicitly* depend on glib2 (that is, would the sources fail to  
> preprocess were the glib headers moved aside temporarily, or to  
> link in the case of missing glib libraries)? Or is the glib2  
> dependency listed only 'cause gtk2 itself depends on it? In case of  
> the former, the dependency needs to be clearly stated; in case of  
> the latter, it's unnecessary bloat in my opinion.

Right, that should be investigated. I'm not familiar enough with gtk- 
engines2 to know.