Re: [boost] Cmake

Subject: Re: [boost] Cmake
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2017-06-24 17:10:36

On Jun 24, 2017 11:34 AM, "P F" <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. The small number of times I've used package managers I've wrapped
them in scripts that provide repeatable installation for my fellow
developers.

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

In fact, boost also follows scenario #1, as it doesn’t build zlib or bzip2
as part of its build, but rather tries to use a prebuilt binary.

Every time I've used zlib bzip2 I've built them statically into my projects.