Geert Hendrickx wrote:

>>I'm debating whether to add "wish" (and similarly for "tclsh") to the 
>>tools framework, so that a package that wanted "wish" at run-time would 
>>set instead:
>>
>>	USE_TOOLS+=	wish:run
>>
>>The tools framework would then take care of providing a common place for 
>>setting the dependency on the tk package, though it may be overridden on 
>>a per-package basis.  This matches what I've currently done with "perl", 
>>i.e., packages that want just want the "perl" interpreter at run-time 
>>are setting:
>>
>>	USE_TOOLS+=	perl:run
>>
>>Note that the perl dependency in the tools framework is looser than the 
>>one in perl5/buildlink3.mk because if a package just wants the perl 
>>interpreter, then some older version of perl can still be used.
> 
> 
> Hm, USE_TOOLS doesn't seem appropriate here, since that's for build-time
> depenendencies.  But we may want to make a distriction between proper "run"
> dependencies vs "link" dependencies though.  This is important e.g. when
> you want to statically link your packages (in that case "link" dependencies
> are more like build dependencies, whereas you will always still need the
> run dependencies at run-time).  

Actually, USE_TOOLS can be used for both build- and run-time 
dependencies.  That was why I implemented modifiers such as ":run", as 
in the examples I gave above.  If we ever get to the point where pkgsrc 
supports statically linking packages, then it's a simple matter to make 
the buildlink framework use build dependencies instead of full 
dependencies by appropriately setting BUILDLINK_DEPMETHOD.<pkg>.

	Cheers,

	-- Johnny Lam <jlam@pkgsrc.org>