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

Juan Manuel Palacios jmpp at macports.org
Mon Oct 8 14:02:17 PDT 2007


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

	Regards,...


-jmpp




More information about the macports-dev mailing list