[build2] build2 0.15.0 pre-release notes for distribution package maintainers

[Boris Kolpackov]

The build2 0.15.0 release is (hopefully) a few weeks out and I would
like to give a heads-up to distribution package maintainers (and anyone
else interested) about build-related changes in case they want to test
things out using the staged version of the toolchain[0] and report
any issues or concerns before the final release.


1. The libpkgconf dependency has been replaced with libpkg-config.

We have forked libpkgconf as libpkg-config[1] and by default build2
now uses this library for pkg-config handling (and it is now bundled
in build2-toolchain instead of libpkgconf).

We sort of soft-forked it already (by not upgrading to newer upstream
versions and applying our own fixes) but the recent attempt[2] to
package build2 for Homebrew forced us to do this properly. See
libpkg-config[1] for background (motivation for the fork, etc).

To ease transition we for now still support building with libpkgconf
if explicitly requested with config.build2.libpkgconf=true if
bootstrapping manually or with --system libpkgconf if using the
build.sh script (see #2 below). For the latter you will also need
to use the CPATH variable to communicate the libpkgconf include
directory, for example:

$ CPATH=/usr/local/include/pkgconf ./build.sh --local --system libpkgconf g++

Note that libpkgconf is known to have issues on Windows and Mac OS
so this should only be used on Linux and maybe BSDs. Also note that
we will only keep this until upstream (again) breaks backwards
compatibility at which point we will drop this support.


2. Support for using system-installed versions of common libraries.

The build.sh script inside the build2-toolchain archive as well as the
build-install-X.Y.Z.sh install script can now be instructed to use
system-installed versions of common libraries, such as libsqlite3,
instead of building them from source. For example:

$ ./build.sh --system libsqlite3,libpkg-config

Do note, however, that the system-installed version may not have the
desired configuration. One known such case is the build2's use of
SQLite's ATTACH DATABASE to implement support for linked build
configuration. SQLite places a compile-time limit on the number of
databases that can be attached with the default being 10. While this
should be sufficient for normal use, it's not impossible to reach
this limit in more advanced scenarios. So you may want check your
distribution's SQLite configuration before switching.


3. New standard pre-installed build system module.

This release adds one new standard pre-installed build system module:
libbuild2-autoconf[3]. See the earlier post[4] for background on
standard pre-installed modules.


[0] https://build2.org/community.xhtml#stage
[1] https://github.com/build2/libpkg-config/
[2] https://github.com/Homebrew/homebrew-core/pull/101846
[3] https://github.com/build2/libbuild2-autoconf/
[4] https://lists.build2.org/archives/users/2021-January/000862.html