Re: Purpose of mk/find-prefix.mk

["J. Lewis Muir" <jlmuir%imca-cat.org@localhost>]

On 10/20/14 11:52 AM, Greg Troxel wrote:
> "J. Lewis Muir" <jlmuir%imca-cat.org@localhost> writes:
>> 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?

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.

>> 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.

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.

>> 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.

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).

> But 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.

>> 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.

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