[build2] Boost package

[Klaim - Joël Lamotte]

On Fri, 2 Nov 2018 at 12:47, Boris Kolpackov <boris at codesynthesis.com> wrote:
>
> Klaim - Joėl Lamotte <mjklaim at gmail.com> writes:
>
> >  - 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.
>
> I find it hard to believe. Surely you still need bjam/b2/boost-build?

Sorry, I might have not been clear enough about what I was thinking here.
Conan is the easiest to "get a packaged available" to a build2
project. That is, if the user is ok with retrieving binaries (not
sources) packages from conan, it seem easy to "generate" some build2
scripts that exposes targets matching the content of a Conan package.
It seems also ultra-easy to acquire a specific version of the package.
So in the case of conan the potential tool would simply take a bunch
of names and version of packages, retrieve them from the default
package repository (or another) then provide the user the direcrtory
(or maybe a build2 configuration directory) where all the dependencies
are already "available". (I'm mainly thinking about using that setup:
https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml#guide-unpackaged-deps
but with also a manifest generated from a conan's package manifest)

Of course that do not work if you want to get source packages, but I
was thinking of the fastest way to obtain something like boost.

vcpkg imply building locally which basically imply a totally different
approach, as you describe below. But then you hardly get exactly
version of the dependency you want (it's possible but appear super
hard to me).

It's totally different approaches.

> On a more general note, I don't believe a fully automatic conversion
> to build2 (as in, the build system) will be realistic for any non-
> trivial library, let alone something like Boost.
>

We definitely agree on that.
Though I think boost is easier to automatically convert than most
libraries out there.

> The only more-or-less automatic approach that I can think of is to
> wrap the native build system into some kind of special build2 link
> rule. The nice thing about vcpkg (reportedly; we haven't tried this
> ourselves) is that as part of their packaging efforts they make a
> CMake-based build wrapper for whatever native build system is used
> by the package. So if we were to go this route, we would just need
> to interface with this wrapper rather than dealing with multiple
> build systems ourselves.

Indeed, though as I was saying, it's just a little bit harder to get
right than retrieving binary packages from conan and just expose their
content to build2's projects.
But I do think it's unavoidable because most of us want the source
packages, for numerous reasons.

> In contrast, (again, according to my understanding), in Conan you
> write an ad hoc Python script to build the package using whatever
> native build system the package uses. Requiring Python would be
> a non-starter for any integration with build2.

I didn't consider at all this way of doing it because I don't think
(partially because of these dependencies you describe) it's a good
approach. After all, I just want my build2 project to be able to
link/use headers from Boost and other packages.
However for boost, I'm mostly ok if it's packages of header-only
libraries, so retrieving directly the packages and making it visible
to build2 should be far enough for a lot of people.

It might not be the best approach though, it just look like the "simplest".