Re: [boost] Switch to CMake -- Analysis

Subject: Re: [boost] Switch to CMake -- Analysis
From: paul (pfultz2_at_[hidden])
Date: 2017-07-21 17:02:25

On Fri, 2017-07-21 at 17:39 +0200, Thomas Heller via Boost wrote:
> Am 21.07.2017 5:18 nachm. schrieb "Andrey Semashev via Boost" <
> boost_at_[hidden]>:
> 
> On 07/21/17 18:00, Thomas Heller via Boost wrote:
> 
> > 
> > Am 21.07.2017 4:55 nachm. schrieb "paul" <pfultz2_at_[hidden]>:
> > 
> > On Fri, 2017-07-21 at 16:21 +0200, Thomas Heller via Boost wrote:
> > 
> > > 
> > > 
> > > All in all, I am pretty confident that a disruptive switch will hurt
> > > Boost more than it brings benefit. This already happened. To come to an
> > > end and summarize: Provide proper CMake integration, such that Boost is
> > > consumable by those (while you are at it, don't forget meson, bazel and
> > > pkg-config).
> > > 
> > pkg-config is build-indenpendent so can be consumed by meson and bazel.
> > 
> > It's also consumable by cmake. Doesn't propagate build properties though.
> > Only plain and simple strings on how to invoke the compiler/linker.
> > Anything else is not the default behavior.
> > 
> It does, at least with regard to macros to define, include/library
> directories to add and libraries to link with. Or do you have different
> properties in mind?
> 
> 
> Well, recently, cmake got support for c++ feature properties for example.
> The big advantage is that the flags carry on semantics and the build system
> is able to determine conflicts etc.

Well I think you can encode those using pkg-config files. You can use the
`replaces` and `conflicts` fields to help pkg-config resolve the flag. The C++
features properties still lack maturity with cmake.

> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman
> /listinfo.cgi/boost
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boo
> st