Re: [boost] Cmake

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]>
> wrote:
>> 
>> 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
> over
>> the compilation variant and want it to be uniform over all the external
>> dependencies.
> 
> 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
> need.

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
> developers.

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.