tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg-config and cached *.pc files under the work directory
Dave Tyson <dtyson%anduin.org.uk@localhost> writes:
> I have been trying to understand why when building MesaLib with the llvm
> and dri options it fails to find dri3proto yet finds dri2proto without
> any problem. (as per thread in pkgsrc-users)
>
> Both config files exist in /usr/X11R7/lib/pkgconfig and so I was baffled
> why the configure script failed to find several packages.
>
> A bit of grovelling in the internals of the package build process shows
> that pkg-config actually uses a local copy of the package configuration
> files in:
>
> /usr/pkgsrc/graphics/MesaLib/work/.buildlink/lib/pkgconfig
>
> and there is no surprise that this has an entry for dri2proto.pc, but
> none for dri3proto.pc (and a few other required config files)!
>
> The question is what guides the package install process in deciding
> which files to copy into the above directory from the source files in
> the base and elsewhere. The pkgsrc guide seems to be silent on this
> area.
First, you really need to remove all work/ directories before trying to
build anything, especially after changing anything. You might well not
be having problems from stale work directories, but it's a common issue.
pkgsrc has a facility called "buildlink3". The point is to create a
directory of links to files that belong to packages that are declared as
dependencies, as part of a scheme to hide files that are not explicitly
recorded as dependencies.
Generally, packages have a line like:
.include "../../x11/gtk2/buildlink3.mk"
which declares gtk2 as a manifest dependency. This ensures that the
package is installed, and creates symlinks to the .h files, the libs,
and the pkgconfig file.
For packages that can be from base or from pkgsrc, there is a
"builtin.mk" that decides if the base system version can be used, or if
it's necessary to use the pkgsrc version. Either way, the
headers/libs/pkgconfig files are provided by symlinks.
Then, the build uses the bl3 symlinks and tries to avoid using normal
paths that pick up installed packages. The point is to avoid having
packages that are installed but not declared as manifest dependencies be
visible to the build, so that packages are not different because some
non-declared package happens to be installed.
So in the case of MesaLib, it may be that the manifest dependencies are
not quite right. It's fairly complicated, and I don't understand it
well enough to say. (I would expect that without the dri option, all
kinds of dri would be hidden.)
In work/.buildlink, there will be logs of what was included. You can
read the bl3 and builtin.mk files and print variables with "make
show-vars VARNAMES=USE_BUILTIN.foo" to figure out what choices were
made. No magic, just more details than normal people have the patience
to understand.
If you do "make PKG_DEBUG_LEVEL=1", you'll get extra debug output that
will explain many of the steps. Or 2, if you can stand to read it.
Home |
Main Index |
Thread Index |
Old Index