[build2] Boost package

[Boris Kolpackov]

Klaim - Joël Lamotte <mjklaim at gmail.com> writes:

> My current understanding is that the CMake scripts for one package for
> one specific version of vcpkg will be compatible with the
> corresponding library code at the specific version it was designed for
> (most of the time with the last release) but is not guaranteed to work
> with previous ones, as it relies on variable and library-specific
> CMake scripts that might not work as the package scripts expect.

Yes, I believe this is correct.

What we can do in build2, however, is to bundle the corresponding
version of the necessary CMake scripts (and/or depend on the
corresponding version of the vcpkg "helper" package that would
contain them) for each package version. In other words, making
a build2 package out of vcpkg would result in a real build2
package archive. And you may end up building libfoo-1.2.3 using
vcpkg-123abcde and libbar-2.3.4 using vcpkg-124abcde.

There is still no guarantee that the two are compatible (which
is where establishing version constraints I mentioned earlier
comes into play). But that we should hopefully be able to sort
out with CI.


> It's important to keep this setup in mind: most sizeable companies
> will avoid making their devs compiling common dependencies all the
> time, so they will provide a binary package repository for all
> necessary platforms.
> My understanding is that it shouldn't be a problem for build2 for code
> compiled with it, but for other binaries (like some acquired by buying
> them to companies only selling the binary version), it's still
> necessary to have an easy way to add binary libraries, with all the
> issues that can have.

Our current plan (which, admittedly, might change based on feedback)
for handling this is as follows:

1. For binary-only (e.g., proprietary) dependencies the answer is to
   use the system package manager (build2 already provides support for
   satisfying dependecies with system-installed packages).

2. For packages that are available in source the idea is to reuse
   distributed compilation and caching (and the precise binary
   compatibility guarantees that it will require). In other words,
   you should be able to reuse someone else's compilation results
   whether they are for a third party dependency or for your own
   code.

> I intend to start working on projects related to these discussion in
> the coming days, I'll keep you updated. I also have some reports to
> post here, after I edit them a bit.

Sounds great!