[build2] Boost package

[Klaim - Joël Lamotte]

On Thu, 1 Nov 2018 at 12:22, Boris Kolpackov <boris at codesynthesis.com> wrote:
> > I can see that some of the conan people have tried to modulize boost for
> > conan, and maybe build2 could benefit from some of that work ?
>
> Yes, there are some thoughts/ideas like that, except we were looking into
> vcpkg (which has managed to split Boost into individual libraries and
> document their dependencies -- not sure if Conan folks did the same of
> if it's one gian library).

They did the same (Conan's  version was done by the main previous
maintainer of Boost.Build).
I took a look at both vcpkg and conan packages and repository APIs.
It's too early to say what could be done exactly but I can say this:

 - The conan packages looks far easier to convert to build2 (I only
looked at boost packages though). From what I understand, package
descriptions are simple enough that no additional tools is needed to
process them.
 - My understanding so far is that only conan is setup in a way that
could allow build2 to benefit from package versions. vcpkg's way of
handling it migth make things hard but not impossible (you'd have to
find the right commit for that version of that library in their main
branch instead of just looking for a tag).
 - vcpkg relying on some CMake subset/specific-macros to unify how
their packages are described works well for not-too-complex projects
like boost, but not well for something like Ogre3D (which I tend use
as a worst-case of CMake usage, which still manage to work). Basically
having the possibility of CMake macros in the package description
could make things hard. Though I might be wrong, because if their
scripts are enough to just build using CMake only, then it's possible
to generate something that build2 will understand.
 - vcpkg have far more packages than conan
 - conan packages are most of the time binary only, which is not a
problem if you declare that you sitll want to use it; vcpkg imply
building locally using CMake which is gives both advantages and

I started thinking about how to make some tool to help with that
(instead of making build2 directly aware of these), with at least the
case of Boost in mind as the main set of libraries to make available,
but it's still in early thinking, I couldn't reserve time to focus on
writing some experiments.
Obviously I'll report here if I manage to make something usable.

>
> > Is this a problem related to the header (and c++-20 module) only package
> > handling, that is yet not quite possible (except for a dummy stub)?
>
> I am not sure what you refer to here. I don't think Boost has any
> support for consuming it as C++ modules rather than headers.
>

I didn't understand the question either but if it's about build2s
habitlity to represent/define header-only libraries, I didn't try yet
to use it that way but it seems to not be a problem in current
version.

Joël