tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Purpose of mk/

"J. Lewis Muir" <> writes:

> It would be cool if the tools framework would let me specify a tool via
> USE_TOOLS in my package Makefile without it actually being an official
> tool.

That might be useful, but I wonder how many tools there are that truly
expect to be used by only one package.  ant is certainly not in that
category.  I would suggest that you look at what it takes to add it to
the existing framework before deciding to add a mechanism to declare
local tools.  Or at least until we find a tool needed for some package
that we can confidently declare to be so local to that package that it
would be clutter under mk/.

> Got it.  And a tool is normally invoked in a bare form (e.g. "ant") not
> as an absolute path, right?  The pkgsrc developer's guide says that the
> tools framework defines the variable for tool "foo" which
> contains the full path to the tool.  But I'm assuming that's helpful for
> debugging, but I don't need to use that to invoke the tool.

I think ${} should be used to invoke the tool.  That's the
point of figuring out the path - to make sure that the same program that
was judged adequate is invoked.

>> Generally, using the user PATH is not so great, because it leads to
>> inconsistent results.
> Understood.  But for a tool, it is good to depend upon the PATH variable
> of the environment because it has been set by the tools framework to the
> correct value, right?

I think the tools framework sets the pathname of the tool itself, not a
search path.  The tools framework and may have OS-specific
paths to check for tools that are adequate.

Attachment: pgpi4b_s4NyHO.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index