Subject: Re: [boost] Cmake
From: P F (pfultz2_at_[hidden])
Date: 2017-06-24 17:17:26
> On Jun 24, 2017, at 12:10 PM, Rene Rivera via Boost <boost_at_[hidden]> wrote:
> On Jun 24, 2017 11:34 AM, "P F" <pfultz2_at_[hidden] <mailto:pfultz2_at_[hidden]>> wrote:
>> On Jun 24, 2017, at 11:17 AM, Rene Rivera via Boost <boost_at_[hidden]>
>> On Sat, Jun 24, 2017 at 11:07 AM, Stefan Seefeld via Boost <
>> boost_at_[hidden]> wrote:
>>> So what's the reason you prefer (at least in that context) building
>>> boost as an integral part of another project, rather than referring to
>>> it as an external (pre-installed) dependency ?
>> Depends on the project... But generally because I need precise control
>> the compilation variant and want it to be uniform over all the external
> But isnât that what a package manager does? The point of scenario #1 is
> that it enables a package manager or dependency tool to do this.
> I've been doing this before package managers existed that could do that.
> And so I haven't found a package manager that will do it as flexible as I
What flexibility do you need?
> The small number of times I've used package managers I've wrapped
> them in scripts that provide repeatable installation for my fellow
What areas does it lack repeatability? Both conan and cget provide a toolchain definition and pulling down the specific versions. Just curious as to what other areas lack repeatability.
>> That precise control offers the advantage of isolated and
>> predictable building for the project regardless of who builds it (other
>> devs and CI).
> Yea, but for open-source libraries and distros, they will never build the
> software exactly the same way. It can be built in a lot of different
> scenarios. This is why autotools came about to handle this.
> Except for Boost I don't do open source. All my work is closed source
> products. Usually games or game development tools. Where developers doing
> installation is counter productive.
Yes, and scenario #2 works great for internal or proprietary builds.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk