pkgconf: import into the base system

[khorben]

Summary

This introduces the following option:

• MK_PKGCONF: determines if pkgconf and bomtool should be built

Sponsored by: Alpha-Omega, The FreeBSD Foundation

Test Plan

$ make buildworld
$ sudo make installworld
$ /usr/bin/pkgconf --version
2.5.1
$ /usr/bin/pkgconf --cflags --libs zlib
-L/lib -lz

[khorben]

This depends on the vendor import from D56373.

[khorben]

This patch adds /usr/local/etc/pkgconfig/personality.d to -DPERSONALITY_PATH in lib/libpkgconfig/Makefile, as requested by bapt at https://ron-dev.freebsd.org/FreeBSD/src/pulls/9.

[ivy]

lib/libpkgconf/Makefile

20

it would be better to use ${LOCALBASE} for this, rather than hardcoding /usr/local.

[ivy]

etc/mtree/BSD.usr.dist

29

what is creating the libpkgconf-dev package? it appears from lib/libpkgconfig/Makefile that you are putting this in the pkgconf package, not libpkgconf.

[khorben]

This update addresses feedback from bapt, more precisely:

• Moves the option definition for MK_PKGCONF from share/mk/bsd.opts.mk to share/mk/src.opts.mk
• Uses ${LOCALBASE} to refer to /usr/local
• Documents the WITH_PKGCONF and WITHOUT_PKGCONF options
• Sets pkgconf's files as obsolete when installing WITHOUT_PKGCONF.

Thanks!

[khorben]

etc/mtree/BSD.usr.dist

29

I thought this is the place that creates the libpkgconf-dev package; I used prior art to implement this, and haven't been able to verify this part as I haven't been able to convert my systems to pkgbase for testing yet (https://github.com/FreeBSDFoundation/pkgbasify/issues/46). Glad for any pointers.

lib/libpkgconf/Makefile

20

I think this solves it; is it the right way?
bapt also reported this at https://ron-dev.freebsd.org/FreeBSD/src/pulls/9 btw.

[ivy]

etc/mtree/BSD.usr.dist

29

packages are created implicitly by putting things in them, so when you say PACKAGE=foo in a Makefile, you get a foo package. you can also create packages in mtree, but this is almost always wrong, because a package that only contains a directory isn't normally useful. (i.e., you still include the package tag, but it should reference a package that is already created somewhere else.)

right now, your Makefile will give you pkgconf, pkgconf-dev, and pkgconf-dbg. since the development files are in pkgconf-dev, that's probably also what you want to put in mtree.

if you want the runtime libraries to be in a different package, you can set LIB_PACKAGE= in the libpkgconf Makefile to create pkgconf-lib. whether this is a good idea depends on the package... if you expect a lot of things to link to libpkgconfig, it's useful to put it in its own package, but if the only thing likely to use it is pkgconf itself, there's no point.

lib/libpkgconf/Makefile

20

yep, this looks fine.

[ivy]

this is also missing package definitions in release/packages/ucl, so it will break the package build. you can copy an existing ucl file and modify it as appropriate; usually all you need is a comment and a description.

let me know if you want me to test the package build.

[khorben]

This addresses feedback from ivy, moving /usr/include/pkgconf into the pkgconf-dev package.
It also adds the files in /usr/include/pkgconf to the list of obsolete files when disabling the pkgconf option.

etc/mtree/BSD.usr.dist

29

Thanks for clarifying! I also think it should go into the pkgconf-dev package instead.