"J. Lewis Muir" <jlmuir%imca-cat.org@localhost> writes:
> So, PREFIX is the right variable to use when referring to the package's
> own installation path. I think all the answers agree with this.
I think so, but in general it's helpful to read the makefiles. Prefix
is set in mk/bsd.pkg.use.mk, and you can see that it can be LOCALBASE or
other values, depending. So it seems clear that PREFIX is determined,
and then should be used.
> I'm hearing that LOCALBASE is the right variable to use at build-time if
> constructing "-I" or "-L" arguments to the compiler, or, more generally,
> when referring to the prefix of other packages.
I don't think that's true. I would argue that if you need to refer to
prefixes of other packages, then you should be including a bl3 file and
that file should set the variables you need. That way, the information
is modularized behind an abstraction boundary, even if newly defined.
> On the other hand, some answers say mk/find-prefix.mk (or EVAL_PREFIX)
> is the right thing to be using for determining the prefix of a
> build-time dependency. Why is mk/find-prefix.mk better than LOCALBASE?
The basic issue is that LOCALBASE is the configured location where
packages normally should be built. Which is different from where they
were built, maybe.
> Is 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?
> I'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.
> Let'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 my
> package. I would specify my build dependency like this:
>
> BUILD_DEPENDS+= apache-ant-[0-9]*:../../devel/apache-ant
>
> Then, I would specify a do-build target like this:
>
> FIND_PREFIX:= ANT_PREFIX=apache-ant
> .include "../../mk/find-prefix.mk"
>
> do-build:
> 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.
But really ant should be a tool.
> Now, 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
> "ant" is more appropriate, like this:
>
> do-build:
> cd ${WORKSRC} && ant
The builtin.mk should be figuring out and setting the path to ant.
> This 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.
Attachment:
pgp0xgjQnz5Zo.pgp
Description: PGP signature