"J. Lewis Muir" <jlmuir%imca-cat.org@localhost> 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 TOOLS_PATH.foo 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 ${TOOLS_PATH.foo} 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 builtin.mk may have OS-specific
paths to check for tools that are adequate.
Attachment:
pgpi4b_s4NyHO.pgp
Description: PGP signature