On Wed, 2017-09-20 at 18:26 -0400, Edward Diener via Boost wrote:

On 9/20/2017 6:01 PM, paul via Boost wrote:

...

Hi,

So the Daniel Pfeifer has agreed to be the review manager for the Boost Cmake Modules. I would like ask for an endorsement so we can schedule a formal review for BCM.

I will make the endorsement.

Thanks

I have also opened the issue of lack of CMake support for testing a  compile, and testing a link, ala Boost Build, on the CMake developers  list. Robert Ramey, among a few others, was helpful in getting the  discussion noticed on the CMake users list and per suggestions there I  reiterated my points on the CMake developers list and got an initial  acknowledgement there. If others can chime in on the CMake developers  list it would be helpful. I understand your code to emulate Boost Build  compile tests, and I likewise have suggested a way for bcm to emulate  Boost Build link tests, but I considered those solutions more of a  kludge than anything, although the best we can do with CMake as it now  exists to emulate Boost Build testing. So my effort on the CMake mailing  lists is really to get the CMake developers to realize that while CMake  has run-time testing, it does not have compile-time testing, which is a  reality in the C++ programming world and certainly a reality for a  number of Boost libraries.

Although it would be useful to have native features for this, it really is the lowest priority. The top needed features for cmake are: - Recording the module for imported targets: https://gitlab.kitware.com/cmake/cmake/issues/17006 - Having `TARGET_EXISTS` generator expression: https://gitlab.kitware.com/cmake/cmake/issues/17123 - RPATH emulation for windows when running tests The first two items are currently emulated or uses workarounds in BCM, and the last item is on my TODO to finish before an official formal review.  Ultimately, adding compile-time tests are fairly straightforward compared to the workarounds needed for these features. Although, I do have a workaround to deal with parallel compile tests correctly, so a native feature could possible help if cmake developers are aware of the current issues. I plan to write a design rational document over how each of these are used, and what problems they help to solve. Paul .

On Thu, 2017-09-21 at 19:18 +0200, Vicente J. Botet Escriba wrote:

Le 21/09/2017 à 00:01, paul via Boost a écrit :

...

Hi,

So the Daniel Pfeifer has agreed to be the review manager for the Boost Cmake Modules. I would like ask for an endorsement so we can schedule a formal review for BCM.

Hi Paul,

I've surely missed the announce of BCM.

Could you give the link to the doc and git repository?

Oops, sorry: https://github.com/boost-cmake/bcm http://bcm.readthedocs.io/en/latest/ .

Have a look at Hunter for cmake. It's an automatic dependency manager, fetcher, builder, cache for cmake dependencies. It understands toolchain files and ensures that the correct toolchain is used to build and link the dependencies of your project. It also ensures that dependencies built with one toolchain cannot to accidentally used on a project built with another. It segregates dependency installations by toolchain (i.e. target) and configuration settings. https://github.com/ruslo/hunter It integrates with polly, a collection of standard toolchains https://github.com/ruslo/polly And also with Sugar - the clean source file management and Doxygen support that cmake lacks out of the box. https://github.com/ruslo/sugar Hunter takes a little while to get used to - the documentation is a little terse. But once you get it, you realise that it's solved dependency management for c++. Ping me direct if you need some help with it or to be pointed at a demo. Here's a little play project I knocked up using it. It should compile for any target without modification, provided you use one of the toolchains (-T option) in polly, or a correct toolchain of your own. If you're building for the host system there's no need to specify a toolchain. https://github.com/madmongo1/goblins Regards, R On 22 September 2017 at 01:37, James E. King, III via Boost < boost@lists.boost.org> wrote:

On Thu, Sep 21, 2017 at 2:24 PM, paul via Boost wrote:

...

...

Le 21/09/2017 à 00:01, paul via Boost a écrit :

...

Hi,

So the Daniel Pfeifer has agreed to be the review manager for the

Boost

...

Cmake Modules. I would like ask for an endorsement so we can schedule a

On Thu, 2017-09-21 at 19:18 +0200, Vicente J. Botet Escriba wrote: formal

...

...

review for BCM.

Hi Paul,

I've surely missed the announce of BCM.

Could you give the link to the doc and git repository?

Oops, sorry:

https://github.com/boost-cmake/bcm

http://bcm.readthedocs.io/en/latest/

It makes sense to have a standard repository of cmake modules that can be acquired during the build process and shared among all the projects.

I have over 10 years experience using cmake on both large commercial projects as well as open source projects (Apache Thrift is in the middle of converting from automake) on Windows and Linux. If you need another pair of eyes on reviews I'd be happy to do so. Has a baseline minimum cmake version been established yet? I'd recommend at least 3.2.3 to make sure the language support for C++ is there, especially in configuration; and later would be even better.

- Jim

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