[build2] Boost package
boris at codesynthesis.com
Mon Nov 5 14:57:34 UTC 2018
Klaim - Joël Lamotte <mjklaim at gmail.com> writes:
> 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.
Ah, binary packages, I haven't even thought about that.
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
> 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.
> 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.
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
More information about the users