Subject: Usage of USE_TOOLS (was: Re: CVS commit: pkgsrc/mk/tools)
To: None <tech-pkg@NetBSD.org>
From: Min Sik Kim <email@example.com>
Date: 11/19/2007 14:47:35
(Moved from pkgsrc-changes@)
On Nov 18, 2007, at 3:55 PM, Masao Uebayashi wrote:
>>> Please back this out. USE_TOOLS+= perl is the canonical way to
>>> depend on
>>> Perl and this breaks dependency handling completely.
>> Then I am afraid we are abusing the tools framework. We shouldn't
>> assume that the tools framework adds dependencies on pkgsrc packages;
>> it may select native packages instead.
> I'd want to clarify this point too.
> If USE_TOOLS is what Min means here, it should be always
> BUILD_DEPENDS, I think. Is this correct?
It is documented in the pkgsrc guide (Sec 18.4):
The USE_TOOLS definition is used both internally by pkgsrc and also
individual packages to define what commands are needed for building
(like BUILD_DEPENDS) or for later run-time of an installed packaged
DEPENDS). If the native system provides an adequate tool, then in
many cases, a
pkgsrc package will not be used.
So USE_TOOLS is not a replacement for DEPENDS or BUILD_DEPENDS.
Currently, some packages set USE_TOOLS when they need DEPENDS. For
example, pkgtools/pkglint should not use USE_TOOLS+=perl, because it
requires pkgsrc perl with specific perl modules. However, letting the
tools framework use native perl as a tool (as I did for Darwin) does
not break such packages; they already get dependency on pkgsrc perl
implicitly through the perl modules they depend on.
I've fixed wrong assumptions that USE_TOOLS+=perl brings in pkgsrc
perl, and now it seems that both packages depending on pkgsrc perl and
packages using perl as a tool build fine on Darwin. But there was an
objection to these changes on pkgsrc-changes@.
I don't think using native perl as a tool will break existing
packages. Native perl will be used only when a "perl" interpreter is
all the package needs. Other packages using additional perl modules
will still use pkgsrc perl. We are already doing the same thing for
many interpreters including Tcl, Tk, and shells.
Should we make perl an exception in the tools framework?