Post by Greg TroxelPost by J. Lewis MuirIs LOCALBASE the right variable to use at *run-time* if referring to
the prefix of another package? For example, say I want to embed in
a program provided by my package the absolute path of a program on
which my package has a run-time dependency. Is LOCALBASE the right
choice?
I find this question surprising, because it seems to be that the
proper way is for the upstream program to use configure and find the
path and then substitute it, all without pkgsrc's help. Or are you
trying to patch a program that doesn't do this and should?
This is for any software that does not use GNU Autotools. I actually
prefer not to use Autotools for software I write. I prefer just default
make variables in Makefile that can be overridden from the make command
line invocation (e.g. "make PREFIX=/opt"). This works well, I think,
and it works really nicely for packaging since the packager knows where
things are and can just set them rather than trying to trick Autotools
into figuring out the right things.
But maybe my no-Autotools approach doesn't scale well; I don't know.
Post by Greg TroxelPost by J. Lewis MuirI'm still wondering about the best way to invoke a build-dependency
program during the build phase of my package. In particular, I'm
concerned about the case where the build-dependency is satisfied by a
built-in. I think a concrete example is the easiest way to discuss
this.
We have talked about this off and on in the context of cross building.
Thinking about cross is harder, but makes things easier to understand.
If you are running a program at build time, then it isn't a build
dependency (something you link against) but a tool dependency (a
program you run). A key point is that build deps need to be in the
target architecture/os, and tool deps in the host architecture/os
(using target and host in the normal sense, not the Canadian cross
autoonf sense).
So a build-dependency satisfied by a builtin when you run a program is
really a tool dependency and should be added to the tools framework.
Maybe the tools framework should make this easier.
Interesting. Yes, that sounds really good.
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. So, all the existing tool stuff would stay, but the syntax could
be extended to allow specifying the package of a tool, and for any tool
that is not an official tool, the tools framework could create a symlink
or wrapper script for the tool that just invokes the right tool just
like the other official tools but without any additional behavior.
For example, in the case of ant, I could have this in my Makefile:
USE_TOOLS += ant:../../devel/apache-ant
The tools framework would create a symlink or wrapper script for the
ant program which would in turn use the ant program installed by
devel/apache-ant or the built-in found by devel/apache-ant/builtin.mk.
I could then use a bare "ant" just like an officially provided tool:
do-build:
cd ${WORKSRC} && ant
Since ant has been declared as a tool, I am assured that the tools
framework has arranged for the ant symlink or wrapper script to be found
on the shell's executable search path first.
Post by Greg TroxelPost by J. Lewis MuirLet's say I have a build dependency on apache-ant because I want to
use the ant program it provides to build some Java source files for
BUILD_DEPENDS+= apache-ant-[0-9]*:../../devel/apache-ant
FIND_PREFIX:= ANT_PREFIX=apache-ant
.include "../../mk/find-prefix.mk"
cd ${WORKSRC} && "${ANT_PREFIX}/bin/ant"
Why is that better than "${PREFIX}/bin/ant" or
"${LOCALBASE}/bin/ant"?
Because ant might be built with some other JAVABASE prefix in some
future change to pkgsrc that you don't know about.
OK, so you're saying it's possible that the ant program would not be
installed at ${PREFIX}/bin/ant in the future, and for this reason, using
mk/find-prefix.mk is better because it would be able to figure out
where ant was actually installed (obviously unlike the case of using
${PREFIX}/bin/ant).
Post by Greg TroxelBut really ant should be a tool.
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.
Post by Greg TroxelPost by J. Lewis MuirNow, let's go one step further and pretend that devel/apache-ant is
satisfied as a built-in (i.e. my base system comes with apache-ant by
default and devel/apache-ant has a builtin.mk). In this case, the
ant program might be at /usr/bin/ant, or some other path *not* under
the pkgsrc LOCALBASE. Will mk/find-prefix.mk work in this case? I'm
worried that it won't. This makes me wonder if a bare invocation of
cd ${WORKSRC} && ant
The builtin.mk should be figuring out and setting the path to ant.
Post by J. Lewis MuirThis assumes pkgsrc sets up the PATH environment variable (or
wrappers?) to make my do-build ant invocation find the correct
ant program (from pkgsrc or from the (built-in) base system). Is
this valid? If so, is this actually better than any absolute path
invocation because it works regardless of whether the program is from
a pkgsrc package or the base system (built-in)?
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?
Thank you!
Lewis