Arch Linux

Package: Boost 1.71.0-1

Description:

First post here. If there is a better way of addressing `PKGBUILD` issues, please tell me.
I would have liked to add a comment to the package page instead (as in AUR), but there seems to be no such way for packages in standard repos.

The `PKGBUILD` for Boost v1.71, as obtained by `asp checkout boost; cd boost/trunk`, needs to package Boost's additions to the `/usr/lib/cmake/` tree properly.

Presumably, the additions to `/usr/lib/cmake/` belong in the `boost` package where developer support files go, not in `boost-libs`. The current `PKGBUILD` version does not handle `lib/cmake` specially, which causes `/usr/lib/cmake/` to end up in `boost-libs`, and missing Python3-related CMake support files completely.
This in turn causes failure of detection of Boost.Python3 support in CMake-based software.

Steps to reproduce:

* `pacman -Qlp boost-libs-1.71.0-1-x86_64.pkg.tar.xz` lists `/usr/lib/cmake/` but should not.
* `pacman -Qlp boost-1.71.0-1-x86_64.pkg.tar.xz` does not list `/usr/lib/cmake/*` but should;
and particularly should include files for both Python2.7 and Python3.7:

```
/usr/lib/cmake/boost_numpy-1.71.0/libboost_numpy-variant-shared-py2.7.cmake
/usr/lib/cmake/boost_numpy-1.71.0/libboost_numpy-variant-shared-py3.7.cmake
/usr/lib/cmake/boost_numpy-1.71.0/libboost_numpy-variant-static-py2.7.cmake
/usr/lib/cmake/boost_numpy-1.71.0/libboost_numpy-variant-static-py3.7.cmake
/usr/lib/cmake/boost_python-1.71.0/libboost_python-variant-shared-py2.7.cmake
/usr/lib/cmake/boost_python-1.71.0/libboost_python-variant-shared-py3.7.cmake
/usr/lib/cmake/boost_python-1.71.0/libboost_python-variant-static-py2.7.cmake
/usr/lib/cmake/boost_python-1.71.0/libboost_python-variant-static-py3.7.cmake
```

Proposed Fix:

I have attached a patch for `PKGBUILD`. This changes the `package_*` functions to move the CMake support files, including Python3-related ones, into the `boost` package.

Checks:

The packaging approach so far has been to copy stuff such as `include` from the python2-related stagedir, but overwriting only stuff in `lib` from the python3 stagedir. This leaves potential for inconsistencies. The proposed patch does not alter that approach and in fact continues it, in order to remain minimal.

I have manually issued some `diff -rq` on the two stagedirs to verify that overlapping files are identical, so the packaging does not introduce inconsistencies.