[build2] Boost package

[Klaim - Joël Lamotte]

On Mon, 5 Nov 2018 at 15:57, Boris Kolpackov <boris at codesynthesis.com> wrote:
>
> Klaim - Joėl Lamotte <mjklaim at gmail.com> writes:
> Speaking of exposing targets, vcpkg has a notion of CMake toolchain
> files (see vcpkg/scripts/toolchain/) which seem to be a general CMake
> mechanism, not just specific to vcpkg. Do you know if Conan can consume
> these?

My current understanding is that Conan is agnostic of the build system
but have tools to take into account CMake scripts in particular.
However, I don't think it tries to interact with variable sets in such
scripts, though I might be wrong. I'll try to research more about
that.

>
> > 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).
>
> Yes, it is hard if you are using vcpkg because it operates in terms
> of "frozen" snapshots of all its packages. But if we sidestep vcpkg
> and go directly to its CMake interface, we can have multiple versions
> of the same package quite easily. We may need to establish some
> version constraints for dependencies since that information is not
> present in vcpkg, but that can be done gradually.

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.
I might be wrong but if I understand correctly, the best (most
correct) way to be sure one package version matches the source of the
library would be to align the vcpkg commit you're using with the
library commit you're using.

If it's ok to assume that last vcpkg is always correct (because fixed
progressively) and should work with any version of the library in
question, then indeed it should work or fail regularly if you try to
build old versions of that library.

>
> > 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.
>
> In my experience, binary packages are nice as long as they work. But
> once things break, you can easily spend a couple of weeks chasing some
> obscure binary incompatibility.

I agree, I think it's only a potentially "quick" solution to try to
get some projects working soon but not a long-term goal.

> In fact, if you start thinking about it, what makes you trust the
> binary? And I am not even talking about anything malicious. For
> example, are Conan packages guaranteed to be built on machines
> that are protected against bit rot (ECC memory, check-summed
> filesystems, etc)?

I didn't check that, though I think the default conan repository gives
some basic guarantees, but I think it's also mostly on the reputation
of the uploader (which have their "names" in the repository).

What's sure is that in all companies I've worked with that had several
teams relying on any dependency management tool, they had their own
repository server, with all the code built locally.
Conan can be used that way, like build2 (and qibuild which is the tool
we use at my current job).
So as long as some tool retrieve the binaries from some kind of (ftp,
fs, other) repository, then the security issue is a separate issue
from how to retrieve ready-to-use libraries, because people in these
companies would only use what they compiled themselves (with
commercial exceptions).

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 .

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.

Joël