On Jun 24, 2017, at 12:10 PM, Rene Rivera via Boost
wrote: On Jun 24, 2017 11:34 AM, "P F"
mailto:pfultz2@yahoo.com> wrote: On Jun 24, 2017, at 11:17 AM, Rene Rivera via Boost
wrote: On Sat, Jun 24, 2017 at 11:07 AM, Stefan Seefeld via Boost < boost@lists.boost.org> 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.