[boost] Adding CMakeLists.txt files

[Peter Dimov via Boost]

I'm adding CMakeLists.txt files (mostly generated by
`boostdep --cmake <libname>` to libraries that don't
have one yet.

Apologies (in advance) to all the maintainers for not
going through the proper procedure, but this is much
easier done in bulk (and order matters).



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

[Vinnie Falco via Boost]

On Thu, May 27, 2021 at 3:05 PM Peter Dimov via Boost
<bo...@lists.boost.org> wrote:
> Apologies (in advance) to all the maintainers for not
> going through the proper procedure, but this is much
> easier done in bulk (and order matters).

How are you handling the repositories which are generated from
external repos? I'm thinking of Outcome and ASIO.

Thanks

[Peter Dimov via Boost]

Vinnie Falco wrote:
> On Thu, May 27, 2021 at 3:05 PM Peter Dimov via Boost
> <bo...@lists.boost.org> wrote:
> > Apologies (in advance) to all the maintainers for not going through
> > the proper procedure, but this is much easier done in bulk (and order
> > matters).
>
> How are you handling the repositories which are generated from external
> repos? I'm thinking of Outcome and ASIO.

I'm not handling them in any way at the moment. But Outcome already has
a CMakeLists.txt file, which is largely correct (it's missing a dependency on
Boost::throw_exception and there are a few more cosmetic issues that don't
really matter.)

[Mateusz Loskot via Boost]

On Fri, 28 May 2021 at 02:12, Peter Dimov via Boost

<bo...@lists.boost.org> wrote:
> Vinnie Falco wrote:
> > On Thu, May 27, 2021 at 3:05 PM Peter Dimov via Boost
> > <bo...@lists.boost.org> wrote:
> > > Apologies (in advance) to all the maintainers for not going through
> > > the proper procedure, but this is much easier done in bulk (and order
> > > matters).
> >
> > How are you handling the repositories which are generated from external
> > repos? I'm thinking of Outcome and ASIO.
>
> I'm not handling them in any way at the moment. But Outcome already has
> a CMakeLists.txt file, which is largely correct

Is there any list of requirements for hand-rolled CMakeLists.txt to make
them correct for the Boost CMake?

I maintain custom, developer-oriented and likely broken CML for GIL,
and I don't feel comfortable sabotaging your Boost-wide CMake'ification
efforts, but I haven't got a chance to figure all those requirements
and how to fix my CML.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

[Niall Douglas via Boost]

On 28/05/2021 01:12, Peter Dimov via Boost wrote:

>> How are you handling the repositories which are generated from external
>> repos? I'm thinking of Outcome and ASIO.
>
> I'm not handling them in any way at the moment. But Outcome already has
> a CMakeLists.txt file, which is largely correct (it's missing a dependency on
> Boost::throw_exception and there are a few more cosmetic issues that don't
> really matter.)

I'm pretty sure Outcome *does* have a dependency on Boost::throw_exception:

1. Boost::outcome target link libraries Boost::exception with INTERFACE.

2. Boost::exception target link libraries Boost::throw_exception with
INTERFACE.

3. INTERFACE link libraries is transitive, so by describing a dependency
on Boost::exception, we are declaring a dependency on all the
dependencies of Boost::exception which includes Boost::throw_exception.

Now, you may wish every library to *directly* indicate its dependencies
for some definition of "directly". If that is the case however, then
Outcome would need to list every second and third order dependency of
its first order dependencies. That seems brittle to me.

Niall

[Mike via Boost]

> Gesendet: Freitag, 28. Mai 2021 um 11:42 Uhr
> Von: "Niall Douglas via Boost" <bo...@lists.boost.org>
> An: bo...@lists.boost.org
> Cc: "Niall Douglas" <s_sour...@nedprod.com>
> Betreff: Re: [boost] Adding CMakeLists.txt files

>
> On 28/05/2021 01:12, Peter Dimov via Boost wrote:
>
> >> How are you handling the repositories which are generated from external
> >> repos? I'm thinking of Outcome and ASIO.
> >
> > I'm not handling them in any way at the moment. But Outcome already has
> > a CMakeLists.txt file, which is largely correct (it's missing a dependency on
> > Boost::throw_exception and there are a few more cosmetic issues that don't
> > really matter.)
>
> I'm pretty sure Outcome *does* have a dependency on Boost::throw_exception:
>
> 1. Boost::outcome target link libraries Boost::exception with INTERFACE.
>
> 2. Boost::exception target link libraries Boost::throw_exception with
> INTERFACE.
>
> 3. INTERFACE link libraries is transitive, so by describing a dependency
> on Boost::exception, we are declaring a dependency on all the
> dependencies of Boost::exception which includes Boost::throw_exception.
>
> Now, you may wish every library to *directly* indicate its dependencies
> for some definition of "directly". If that is the case however, then
> Outcome would need to list every second and third order dependency of
> its first order dependencies. That seems brittle to me.

I think the point is that Boost.Outcome directly includes headers from
Boost.ThrowException:
https://github.com/boostorg/outcome/blob/2488966ae1faf88f945ae486647b18edebd805b2/include/boost/outcome/config.hpp#L351

So it should probably also directly declare the dependency on Boost::throw_exception
in the CML.

Mike

[Andrey Semashev via Boost]

On 5/28/21 12:42 PM, Niall Douglas via Boost wrote:
> On 28/05/2021 01:12, Peter Dimov via Boost wrote:
>
>>> How are you handling the repositories which are generated from external
>>> repos? I'm thinking of Outcome and ASIO.
>>
>> I'm not handling them in any way at the moment. But Outcome already has
>> a CMakeLists.txt file, which is largely correct (it's missing a dependency on
>> Boost::throw_exception and there are a few more cosmetic issues that don't
>> really matter.)
>
> I'm pretty sure Outcome *does* have a dependency on Boost::throw_exception:
>
> 1. Boost::outcome target link libraries Boost::exception with INTERFACE.
>
> 2. Boost::exception target link libraries Boost::throw_exception with
> INTERFACE.
>
> 3. INTERFACE link libraries is transitive, so by describing a dependency
> on Boost::exception, we are declaring a dependency on all the
> dependencies of Boost::exception which includes Boost::throw_exception.
>
> Now, you may wish every library to *directly* indicate its dependencies
> for some definition of "directly". If that is the case however, then
> Outcome would need to list every second and third order dependency of
> its first order dependencies. That seems brittle to me.

I think, what Peter sees is that you are including
boost/throw_exception.hpp directly, in boost/outcome/config.hpp, which
means you have a direct dependency on it.

Second order dependencies need not be specified in CMakeLists.txt, CMake
will figure those out as it resolves dependencies.

[Andrey Semashev via Boost]

On 5/28/21 1:04 AM, Peter Dimov via Boost wrote:
> I'm adding CMakeLists.txt files (mostly generated by
> `boostdep --cmake <libname>` to libraries that don't
> have one yet.
>
> Apologies (in advance) to all the maintainers for not
> going through the proper procedure, but this is much
> easier done in bulk (and order matters).

If you are auto-generating CMakeLists.txt, please, make sure that the
generated CMakeLists.txt replicate configuration checks that are
performed in the Jamfile. For example, Boost.Log has a number of
elaborate checks, which I don't think can be converted automatically.

If this cannot be done (and you are not willing to do this manually),
please, don't commit an incomplete CMakeLists.txt. In this case you
could create an issue to ask the maintainer for help.

[Andrey Semashev via Boost]

On 5/28/21 1:58 PM, Andrey Semashev wrote:
> On 5/28/21 1:04 AM, Peter Dimov via Boost wrote:
>> I'm adding CMakeLists.txt files (mostly generated by
>> `boostdep --cmake <libname>` to libraries that don't
>> have one yet.
>>
>> Apologies (in advance) to all the maintainers for not
>> going through the proper procedure, but this is much
>> easier done in bulk (and order matters).
>
> If you are auto-generating CMakeLists.txt, please, make sure that the
> generated CMakeLists.txt replicate configuration checks that are
> performed in the Jamfile. For example, Boost.Log has a number of
> elaborate checks, which I don't think can be converted automatically.
>
> If this cannot be done (and you are not willing to do this manually),
> please, don't commit an incomplete CMakeLists.txt. In this case you
> could create an issue to ask the maintainer for help.

Also, I wanted to thank you for doing this work. I appreciate this is
not a trivial amount of work, and if not for this CMake adoption in
Boost would have largely stalled.

[Peter Dimov via Boost]

Mateusz Loskot wrote:
> Is there any list of requirements for hand-rolled CMakeLists.txt to make them
> correct for the Boost CMake?

Not yet, but I do intend to write that document.

> I maintain custom, developer-oriented and likely broken CML for GIL, and I
> don't feel comfortable sabotaging your Boost-wide CMake'ification efforts,
> but I haven't got a chance to figure all those requirements and how to fix my
> CML.

The easiest way to make a CML compatible with the Boost CMake infrastructure
is to start with the output of `boostdep --cmake gil`, in this case

```
# Generated by `boostdep --cmake gil`
# Copyright 2020 Peter Dimov
# Distributed under the Boost Software License, Version 1.0.
# https://www.boost.org/LICENSE_1_0.txt

cmake_minimum_required(VERSION 3.5...3.16)

project(boost_gil VERSION "${BOOST_SUPERPROJECT_VERSION}" LANGUAGES CXX)

add_library(boost_gil INTERFACE)
add_library(Boost::gil ALIAS boost_gil)

target_include_directories(boost_gil INTERFACE include)

target_link_libraries(boost_gil
INTERFACE
Boost::assert
Boost::concept_check
Boost::config
Boost::container_hash
Boost::core
Boost::filesystem
Boost::integer
Boost::iterator
Boost::mp11
Boost::preprocessor
Boost::type_traits
Boost::variant2
)

if(BUILD_TESTING AND EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/test/CMakeLists.txt")

add_subdirectory(test)

endif()
```

and then make sure that everything else you add is conditioned on either

if(NOT BOOST_SUPERPROJECT_VERSION)

(which means outside the Boost superproject, but you can still in principle be a subproject
in a user master project, consumed via add_subdirectory or FetchContent), or

if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)

which means you're the root project. I think that everything in your existing CML is only
intended to apply in this case.

You can omit the last three lines if you don't intend to integrate your tests in the Boost-wide
CMake testing.

[Peter Dimov via Boost]

Andrey Semashev wrote:
> On 5/28/21 1:04 AM, Peter Dimov via Boost wrote:
> > I'm adding CMakeLists.txt files (mostly generated by `boostdep --cmake
> > <libname>` to libraries that don't have one yet.
> >
> > Apologies (in advance) to all the maintainers for not going through
> > the proper procedure, but this is much easier done in bulk (and order
> > matters).
>
> If you are auto-generating CMakeLists.txt, please, make sure that the
> generated CMakeLists.txt replicate configuration checks that are performed in
> the Jamfile. For example, Boost.Log has a number of elaborate checks, which I
> don't think can be converted automatically.

The autogenerated CML is rarely 100% correct for the compiled libraries. :-)

> If this cannot be done (and you are not willing to do this manually), please,
> don't commit an incomplete CMakeLists.txt. In this case you could create an
> issue to ask the maintainer for help.

I did that manually for some of the compiled libraries (e.g. Thread, Iostreams,
Test), but things like Locale or Context are way too convoluted.

I might try my hand at Stacktrace next, as more or less tractable. :-)

Log depends on Locale, but I would have left it to you either way.

[Cem Bassoy via Boost]

Hi Peter,

I have seen this thread too late. I am maintaining boost.ublas and I needed
to reset the current ublas/develop branch although I am very pro
introducing CMake. Your changes included a merge of master into develop
which contained two commits with the same code changes.

I still have your changes locally if we need to apply your changes
urgently. Is it?

Right now Boost.uBlas is in a transition process where the old matrix and
vector types and functions will be replaced by newer ones. We have already
CMake files from a GSoC student which we are going to apply as soon as our
transition stabilizes:
https://github.com/BoostGSoC20/ublas/tree/feature/cmake

If you want to propose something please create a pull-request from a
feature/branch or get in contact with me if it is very urgent.

Best,
Cem


Am Fr., 28. Mai 2021 um 14:26 Uhr schrieb Peter Dimov via Boost <
bo...@lists.boost.org>:

[Peter Dimov via Boost]

Cem Bassoy wrote:
> Hi Peter,
>
> I have seen this thread too late. I am maintaining boost.ublas and I needed to
> reset the current ublas/develop branch although I am very pro introducing
> CMake. Your changes included a merge of master into develop which
> contained two commits with the same code changes.

The merge just synchronized your branches so that develop was ahead of
master, instead of divergent. It resulted in no actual changes.

> I still have your changes locally if we need to apply your changes urgently. Is
> it?
>
> Right now Boost.uBlas is in a transition process where the old matrix and
> vector types and functions will be replaced by newer ones. We have already
> CMake files from a GSoC student which we are going to apply as soon as our
> transition stabilizes:
> https://github.com/BoostGSoC20/ublas/tree/feature/cmake

Your CMakeLists.txt file presumes that it's a root project, so if you adopt it as-is,
it will be incompatible with the Boost-wide CMake infrastructure. My advice
would be to adopt what I added, perhaps without the testing part at the end,
and then add the above at the end, guarded by

if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
# We're the root project

[Adam Wulkiewicz via Boost]

W dniu 28.05.2021 o 00:04, Peter Dimov via Boost pisze:

> I'm adding CMakeLists.txt files (mostly generated by
> `boostdep --cmake <libname>` to libraries that don't
> have one yet.

Thanks for handling it for us. I have a few questions regarding this
change. :)

I'm curious mostly about target_link_libraries entry and dependencies.
For reference:
https://github.com/boostorg/geometry/commit/f39365963af573d962cc973ed2f33fbbcc8c4c3f

Are these libraries the direct dependencies of Geometry or are these all
of the libraries from the dependency graph?

Are we responsible for maintaining this list or is there some automatic
process in place for that?

Some of these libraries are not used directly or are optional.
Are we free to remove not used libraries from here?
If we drop a dependency can we remove it?

Should optional dependencies be listed?
I'm asking because we provide optional files for adapting e.g. Polygon
models to use them with Geometry. The same is or will be true for
Variant, Variant2 and Any. R-tree support for serialization is optional
as well and enabled with #ifdef. The extensions are optional and exists
only in develop branch. Etc.

Are these dependencies only for includes or also for tests, examples and
sources from documentation?

Regards,
Adam

[Peter Dimov via Boost]

Adam Wulkiewicz wrote:
> W dniu 28.05.2021 o 00:04, Peter Dimov via Boost pisze:
> > I'm adding CMakeLists.txt files (mostly generated by `boostdep --cmake
> > <libname>` to libraries that don't have one yet.
> Thanks for handling it for us. I have a few questions regarding this change. :)
>
> I'm curious mostly about target_link_libraries entry and dependencies.
> For reference:
> https://github.com/boostorg/geometry/commit/f39365963af573d962cc973
> ed2f33fbbcc8c4c3f
>
> Are these libraries the direct dependencies of Geometry or are these all of the
> libraries from the dependency graph?

These are the direct dependencies `boostdep` sees in the header files of the
library. Basically what you see at

https://pdimov.github.io/boostdep-report/develop/geometry.html

> Are we responsible for maintaining this list or is there some automatic process
> in place for that?

No, there's no automatic process. I generated the file with
`boostdep --cmake geometry`, but we won't be overwriting the CMakeLists.txt
files automatically.

> Some of these libraries are not used directly or are optional.
> Are we free to remove not used libraries from here?
> If we drop a dependency can we remove it?
>
> Should optional dependencies be listed?
> I'm asking because we provide optional files for adapting e.g. Polygon models
> to use them with Geometry. The same is or will be true for Variant, Variant2
> and Any. R-tree support for serialization is optional as well and enabled with
> #ifdef. The extensions are optional and exists only in develop branch. Etc.

You have latitude in choosing your dependencies, but with CMake, this is
more consequential. With b2, our current structure copies all the library
headers into boost/, so then any library can include any other without
linking to anything.

With CMake, if you don't link to Boost::foo, the foo headers aren't going
to be in the include path, so if a Geometry header includes a foo header
without Boost::foo being linked to, it will fail to compile.

Whether this is an acceptable outcome or not, is up to you, on a case by
case basis.

> Are these dependencies only for includes or also for tests, examples and
> sources from documentation?

Only for the includes.

[Andrey Semashev via Boost]

On 5/28/21 5:20 PM, Adam Wulkiewicz via Boost wrote:
>
> Should optional dependencies be listed?
> I'm asking because we provide optional files for adapting e.g. Polygon
> models to use them with Geometry. The same is or will be true for
> Variant, Variant2 and Any. R-tree support for serialization is optional
> as well and enabled with #ifdef. The extensions are optional and exists
> only in develop branch. Etc.

Peter already answered this, but I can add that you could conditionally
add optional dependencies in CMake by checking the environment and/or
user configuration options and call target_link_libraries only when
needed. You can see an example in Boost.Filesystem:



https://github.com/boostorg/filesystem/blob/develop/CMakeLists.txt

> Are these dependencies only for includes or also for tests, examples and
> sources from documentation?

The CMakeLists.txt that is in the root library directory is used when
the library is built or consumed by users. So, the PRIVATE dependencies
are those required to build the library (but not to consume it) and
PUBLIC - those required to consume it. IOW, the dependencies from source
files normally go in PRIVATE section and from headers - in PUBLIC. Tests
and examples are not described there.



For tests and examples there may be separate CMakeLists.txt (in test/
and example/) that would describe their respective dependencies,
including on the library itself. Those CMakeLists.txt are not required
to build or consume Boost, so currently are not mandatory.

[Peter Dimov via Boost]

Andrey Semashev wrote:
> The CMakeLists.txt that is in the root library directory is used when the library
> is built or consumed by users. So, the PRIVATE dependencies are those
> required to build the library (but not to consume it) and PUBLIC - those
> required to consume it. IOW, the dependencies from source files normally go
> in PRIVATE section and from headers - in PUBLIC.

Yep. boostdep --cmake does this automatically for compiled libraries - the
dependencies from include/ are marked PUBLIC and those from src/ are marked
as PRIVATE. This doesn't apply to Geometry because it's header-only.

[Edward Diener via Boost]

On 5/28/2021 11:13 AM, Peter Dimov via Boost wrote:
> Andrey Semashev wrote:
>> The CMakeLists.txt that is in the root library directory is used when the library
>> is built or consumed by users. So, the PRIVATE dependencies are those
>> required to build the library (but not to consume it) and PUBLIC - those
>> required to consume it. IOW, the dependencies from source files normally go
>> in PRIVATE section and from headers - in PUBLIC.
>
> Yep. boostdep --cmake does this automatically for compiled libraries - the
> dependencies from include/ are marked PUBLIC and those from src/ are marked
> as PRIVATE. This doesn't apply to Geometry because it's header-only.
>

First off, Peter, thank you very much for all your hard work bringing
CMake to Boost !

Is there documentation anywhere for all this boost cmake stuff ? I have
to make some changes to the cmake things in libraries I maintain, but I
have little idea of what the Boost cmake side of things consists, much
less any expertise with CMake itself. Some sort of documentation would,
as always, be helpful.

[Peter Dimov via Boost]

Edward Diener wrote:
> First off, Peter, thank you very much for all your hard work bringing CMake to
> Boost !
>
> Is there documentation anywhere for all this boost cmake stuff ? I have to

> make some changes to the cmake things in libraries I maintain, ...

Not yet. What changes would you like to make?

[Edward Diener via Boost]

On 5/28/2021 3:26 PM, Peter Dimov via Boost wrote:
> Edward Diener wrote:
>> First off, Peter, thank you very much for all your hard work bringing CMake to
>> Boost !
>>
>> Is there documentation anywhere for all this boost cmake stuff ? I have to
>> make some changes to the cmake things in libraries I maintain, ...
>
> Not yet. What changes would you like to make?

The CMake preprocessor tests do not really follow exactly the b2
preprocessor tests anymore. I will figure it out, but really docs are
needed at sometime in the future regarding CMake with Boost CMake
constructs. You did a great and laborious job so I do not mean to press
you about this.

[Peter Dimov via Boost]

Edward Diener wrote:
> >> Is there documentation anywhere for all this boost cmake stuff ? I
> >> have to make some changes to the cmake things in libraries I maintain, ...
> >
> > Not yet. What changes would you like to make?
>
> The CMake preprocessor tests do not really follow exactly the b2 preprocessor
> tests anymore. I will figure it out, but really docs are needed at sometime in
> the future regarding CMake with Boost CMake constructs. You did a great and
> laborious job so I do not mean to press you about this.

Ah, I see, you've been making changes to the tests. I believe that

https://github.com/boostorg/preprocessor/blob/develop/test/CMakeLists.txt

should be relatively straightforward to figure out, provided you are familiar with
CMake. The full syntax of `boost_test` is

https://github.com/boostorg/cmake/blob/39443f18c03c4568fdf75bed3eaa802c26563663/include/BoostTest.cmake#L40-L47

boost_test( [TYPE type] [PREFIX prefix] [NAME name] [IGNORE_TEST_GLOBALS]
SOURCES sources...
ARGUMENTS args...
LINK_LIBRARIES libs...
COMPILE_DEFINITIONS defs...
COMPILE_OPTIONS opts...
COMPILE_FEATURES features...
)

but I don't think you need anything besides COMPILE_DEFINITIONS. This for
example

[ compile arithmetic.cpp : <define>BOOST_PP_LIMIT_MAG=512 : arithmetic_num_512 ]

translates to

boost_test(TYPE compile NAME arithmetic_num_512 SOURCES arithmetic.cpp COMPILE_DEFINITIONS BOOST_PP_LIMIT_MAG=512)

[Edward Diener via Boost]

I can figure that part of it out, but now the big question:

What do I do to run the tests with CMake and where do I see the output
to verify that any changes I make to the CMakeLists.txt in a test
directory is correct ?

[Peter Dimov via Boost]

Edward Diener wrote:
> I can figure that part of it out, but now the big question:
>
> What do I do to run the tests with CMake and where do I see the output to
> verify that any changes I make to the CMakeLists.txt in a test directory is
> correct ?

From the Boost root:

mkdir __build
cd __build
cmake -DBOOST_ENABLE_CMAKE=1 -DBOOST_INCLUDE_LIBRARIES=preprocessor -DBUILD_TESTING=ON ..
cmake --build .
ctest --output-on-failure

If on Windows,

ctest --output-on-failure -C Debug

(or Release.)

For Preprocessor, the `cmake --build .` line won't do anything, but it's
needed for other libraries.

E.g. https://github.com/boostorg/assert/blob/6047fd69d39a81c4296ba27ee09f22dd0f7671f8/.travis.yml#L323-L328
and https://travis-ci.org/github/boostorg/assert/jobs/771973215

[Edward Diener via Boost]

On 5/29/2021 1:18 PM, Peter Dimov via Boost wrote:

> Edward Diener wrote:
>> I can figure that part of it out, but now the big question:
>>
>> What do I do to run the tests with CMake and where do I see the output to
>> verify that any changes I make to the CMakeLists.txt in a test directory is
>> correct ?
>
> From the Boost root:
>
> mkdir __build
> cd __build
> cmake -DBOOST_ENABLE_CMAKE=1 -DBOOST_INCLUDE_LIBRARIES=preprocessor -DBUILD_TESTING=ON ..
> cmake --build .
> ctest --output-on-failure
>
> If on Windows,
>
> ctest --output-on-failure -C Debug
>
> (or Release.)
>
> For Preprocessor, the `cmake --build .` line won't do anything, but it's
> needed for other libraries.
>
> E.g. https://github.com/boostorg/assert/blob/6047fd69d39a81c4296ba27ee09f22dd0f7671f8/.travis.yml#L323-L328
> and https://travis-ci.org/github/boostorg/assert/jobs/771973215

Thanks, Peter, but how do I tell CMake to use a particular compiler ? In
b2 I specify the toolset on the b2 command line. In CMake I specify what ?

[Peter Dimov via Boost]

Edward Diener wrote:
> Thanks, Peter, but how do I tell CMake to use a particular compiler ? In
> b2 I specify the toolset on the b2 command line. In CMake I specify what ?

There are various ways to control that but the easiest is to set the CC and CXX
environment variables (on POSIX platforms.)

Again, when on Windows, things are a bit different. There you need to
specify the toolset with -T when using the default Visual Studio generator
(or select a generator with -G.)

https://cmake.org/cmake/help/v3.20/manual/cmake.1.html

CMake's philosophy is very different from b2's.

[Edward Diener via Boost]

On 5/29/2021 2:06 PM, Peter Dimov via Boost wrote:
> Edward Diener wrote:
>> Thanks, Peter, but how do I tell CMake to use a particular compiler ? In
>> b2 I specify the toolset on the b2 command line. In CMake I specify what ?
>
> There are various ways to control that but the easiest is to set the CC and CXX
> environment variables (on POSIX platforms.)
>
> Again, when on Windows, things are a bit different. There you need to
> specify the toolset with -T when using the default Visual Studio generator
> (or select a generator with -G.)
>
> https://cmake.org/cmake/help/v3.20/manual/cmake.1.html
>
> CMake's philosophy is very different from b2's.

OK, I will bite <g>.

// Beginning of rant

The difficulty of specifying a compiler to use with CMake, compared with
the elegance of b2's toolset definitions, makes me really wonder why the
majority of the C++ world considers CMake anything but software gone
terribly wrong. I know b2 has some abstruse weaknesses, but specifying a
toolset/definition is not one of them. Maybe I have missed something but
I certainly do not see how some CMake generator equates to a particular
compiler other than the Visual C++ generators, where each generator name
equates to a particular version of VC++. There must be more I am missing
but there is not anything in the CMake documentation I can find which
explains to me how I can specify, for instance, a particular version of
mingw-w64 gcc or clang on Windows for CMake to use. The explanation for
the CMake generators at
https://cmake.org/cmake/help/v3.20/manual/cmake-generators.7.html#manual:cmake-generators(7)
is so pathetic that if I did not know the majority of C++ programmers
swear by CMake I would really have thought that such software
documentation would have doomed such software for popular use eons ago.

// End of rant

[Robert Ramey via Boost]

On 5/28/21 12:53 PM, Peter Dimov via Boost wrote:
> boost_test( [TYPE type] [PREFIX prefix] [NAME name] [IGNORE_TEST_GLOBALS]
> SOURCES sources...
> ARGUMENTS args...
> LINK_LIBRARIES libs...
> COMPILE_DEFINITIONS defs...
> COMPILE_OPTIONS opts...
> COMPILE_FEATURES features...
> )
>

Not to sound ungrateful, but it's a fact that no good deed goes
unpunished, have you considered adding in the information which supports
creating of expanded file hierachy when the target is an IDE. That's a
mouthful, let me give an illustration:

In the CMake files for both safe_numerics and serialization there is
code which generates entries in the IDE when the target is visual studio
or xcode. So I invoke CMake, rum, rum, rum, ... and voila, a file is
created. I double click on that file and the IDE comes up not with just
the sources but all the headers as well. Everything is nicely
categorized and ready to run. It includes targets RUN_ALL, BUILD_All
and something else I forgot. One can also use select any particular
test and just compile/build/run that. Very handy for debugging. And if
I want to change from debug to release or change some compiler switches,
I can just do within the IDE. Anyone can see how I've done it by
looking at CMake files for serialization and safe_numerics. The
serialization one is very, very, very old but still seems to work

Robert Ramey

[Edward Diener via Boost]

On 5/29/2021 2:06 PM, Peter Dimov via Boost wrote:
> Edward Diener wrote:
>> Thanks, Peter, but how do I tell CMake to use a particular compiler ? In
>> b2 I specify the toolset on the b2 command line. In CMake I specify what ?
>
> There are various ways to control that but the easiest is to set the CC and CXX
> environment variables (on POSIX platforms.)
>
> Again, when on Windows, things are a bit different. There you need to
> specify the toolset with -T when using the default Visual Studio generator
> (or select a generator with -G.)
>
> https://cmake.org/cmake/help/v3.20/manual/cmake.1.html
>
> CMake's philosophy is very different from b2's.

I do not see how specifying a -G some_generator chooses a compiler. I
assume each generator has its own way of choosing a compiler but I can
not find any CMake documentation for how to determine this for the
command line. Is this something programmers just guess at or is there
actual documentation on how what command line parameters configure a
particular generator for a particular compiler ? I am being a bit
facetious but I am truly amazed at how anyone uses CMake on Windows with
any generator which is not Visual C++. Even with the Visual C++
generators I can not find any documentation for the specific -T
toolsets, not that I would want to choose any but the default anyway,
for a given Visual C++ generator. Anyone ?

[Rainer Deyke via Boost]

On 30.05.21 03:39, Edward Diener via Boost wrote:
> I do not see how specifying a -G some_generator chooses a compiler. I
> assume each generator has its own way of choosing a compiler but I can
> not find any CMake documentation for how to determine this for the
> command line. Is this something programmers just guess at or is there
> actual documentation on how what command line parameters configure a
> particular generator for a particular compiler ? I am being a bit
> facetious but I am truly amazed at how anyone uses CMake on Windows with
> any generator which is not Visual C++. Even with the Visual C++
> generators I can not find any documentation for the specific -T
> toolsets, not that I would want to choose any but the default anyway,
> for a given Visual C++ generator. Anyone ?

To specify a specific compiler in CMake, use -D CMAKE_CXX_COMPILER or -D
CMAKE_TOOLCHAIN_FILE. This should work in any generator that isn't tied
to a specific compiler.


--
Rainer Deyke (rai...@eldwood.com)

[Alexander Grund via Boost]

> OK, I will bite <g>.
>
> // Beginning of rant
>
> The difficulty of specifying a compiler to use with CMake, compared
> with the elegance of b2's toolset definitions, makes me really wonder
> why the majority of the C++ world considers CMake anything but
> software gone terribly wrong. I know b2 has some abstruse weaknesses,
> but specifying a toolset/definition is not one of them. Maybe I have
> missed something but I certainly do not see how some CMake generator
> equates to a particular compiler other than the Visual C++ generators,
> where each generator name equates to a particular version of VC++.
> There must be more I am missing but there is not anything in the CMake
> documentation I can find which explains to me how I can specify, for
> instance, a particular version of mingw-w64 gcc or clang on Windows
> for CMake to use. The explanation for the CMake generators at
> https://cmake.org/cmake/help/v3.20/manual/cmake-generators.7.html#manual:cmake-generators(7)
> is so pathetic that if I did not know the majority of C++ programmers
> swear by CMake I would really have thought that such software
> documentation would have doomed such software for popular use eons ago.
>
> // End of rant

I'll bite back ;-)

CMake has 2 levels of things you specify because CMake is not a build
system (as B2, make, ninja, ...) but a buildsystem generator.
In short:

- With "-G" you choose the build system to generate files for, e.g. VS
Solutions, Makefiles, Ninja configs, ...
- With CMAKE_<lang>_COMPILER you choose the compiler to use, e.g. `cmake
-DCMAKE_CXX_COMPILER=g++-10 -DCMAKE_C_COMPILER=gcc-10 ...`

The defaults if unset are chosen reasonably. E.g. for make/ninja (make
is the default) it chooses $CC/$CXX (and maybe some fallbacks such es
`cc`) and for the VS generators it chooses the VS compiler for that version.

What do you gain from this? By switching the generator (and nothing
else) you can develop your project in whatever you want. E.g. VS,
VScode, vim (with a language server), ...
I find that quite powerful, especially if you need to develop on
Windows. So for that CMake is better than B2.

However I agree that for building/testing alone B2 is clearly superior.

So yeah, CMake is a tool, it has strengths and weaknesses and has some
historic backage due to the need to be backwards compatible (just as C++
has...)

Best, Alex

[Edward Diener via Boost]

My beef is that the CMake documentation does not tell you what compilers
a particular generator supports, except for the Visual Studio
generators. Period. It is not the process but the lack of documentation.
The lack of documentation is noticeable because I think the average
programmer will first ask: What compiler can I use to do X, Y, and Z,
and how do I specify commands to that compiler. That seems perfectly
natural to me and the fact that one uses -DCMAKE_CXX_COMPILER with the
path to the compiler and options separated by semicolons, is lost amidst
the welter of basic explanations about generators.

[Peter Dimov via Boost]

Alexander Grund wrote:
> CMake has 2 levels of things you specify because CMake is not a build system
> (as B2, make, ninja, ...) but a buildsystem generator.

In CMake parlance, "build system" (or "buildsystem" as they spell it because
we're all German by heart) refers not to make/ninja, which are merely the
engines that execute the build system. It refers to the collection of Makefiles
that in the dark past had to be written by a human in order to implement
the building of a specific project (and contained a bunch of arcane rules and
hacks.)

(That's why when the CMake documentation refers to the build system
author, it has in mind the person writing the CMakeLists.txt file, and not
the maintainer of make or ninja.)

There's an interesting parallel to be made here with jam (the engine),
which sits at the same level as make/ninja, and b2/Boost.Build, which is
the collection of .jam files that implement the high-level building
functionality.

It's interesting how knowing b2 allows one to understand CMake better,
and conversely, familiarity with CMake allows one to understand b2 better.
For example, since CMake separates configure/generate/build phases, one
realizes that b2 has these same phases, except they are executed at once,
rather than in a clearly delineated way, or with separate invocations.

The similarity between CMake and b2 is most visible when using the Ninja
generator. Then

* you describe your targets in a high-level way (in CMakeLists.txt or
Jamfile)
* the tool generates a low-level action/dependency graph (build.ninja,
or an in-memory collection of jam targets)
* the build engine (ninja or bjam) builds the project by executing the
actions in the graph in dependency order.

[Julien Blanc via Boost]

Le lundi 31 mai 2021 à 08:13 -0400, Edward Diener via Boost a écrit :
>
>
> My beef is that the CMake documentation does not tell you what
> compilers
> a particular generator supports, except for the Visual Studio
> generators. Period. 

Because this is an odd question, in a cmake-centric view. Any generator
can launch any compiler (any build step) as part of the build process.
They're orthogonal concepts. Now there is the special case of Visual
Studio, where the build system, the project manager and the compiler
are so tied together that it makes it really hard to use the VS build
system to compile using any other compiler, and vice-versa. Which is
why it is mentioned in the generator documentation.

I do agree, however, that cmake documentation could largely be
improved. Good news is that this is actually happening (documentation
was far worse several years ago, and gets better with every release).

Regards,

Julien

[Peter Dimov via Boost]

Julien Blanc wrote:
> Now there is the special case of Visual Studio, where the build system,
> the project manager and the compiler are so tied together that it makes
> it really hard to use the VS build system to compile using any other
> compiler, and vice-versa.

You can't use arbitrary compiles with MS Build, but you can choose a
toolset with -T. This is the same functionality that can be accessed from
the IDE, in Project Properties > Platform Toolset. E.g. -T v140 selects
msvc-14.0 and -T clang-cl selects, well, clang-cl (at least in principle -
for some reason it have stopped working for me, and neither does
-T llvm. Might be because I'm using the clang-cl installed by Visual Studio
and not the one from llvm.org.)

[Boris via Boost]

Peter Dimov via Boost wrote:

> -T clang-cl selects, well, clang-cl (at least in principle -
> for some reason it have stopped working for me, and neither does
> -T llvm. Might be because I'm using the clang-cl installed by Visual Studio
> and not the one from llvm.org.)
>

*-T clangcl* (no hyphen) works for me, with clang installed by Visual
Studio.

--------------------------------------------------------------------------------------------------------------------------------------------------

Scapix Language Bridge - on the fly C++ bindings for Java, Objective-C,
Swift, Python, JavaScript, C#
https://github.com/scapix-com/scapix

[Peter Dimov via Boost]

Boris wrote:
> Peter Dimov via Boost wrote:
> > -T clang-cl selects, well, clang-cl (at least in principle - for some
> > reason it have stopped working for me, and neither does -T llvm. Might
> > be because I'm using the clang-cl installed by Visual Studio and not
> > the one from llvm.org.)
> >
> *-T clangcl* (no hyphen) works for me, with clang installed by Visual Studio.

Confirmed, thanks.

[Edward Diener via Boost]

On 5/31/2021 12:15 PM, Julien Blanc via Boost wrote:
> Le lundi 31 mai 2021 à 08:13 -0400, Edward Diener via Boost a écrit :
>>
>>
>> My beef is that the CMake documentation does not tell you what
>> compilers
>> a particular generator supports, except for the Visual Studio
>> generators. Period.
>
> Because this is an odd question, in a cmake-centric view. Any generator
> can launch any compiler (any build step) as part of the build process.
> They're orthogonal concepts. Now there is the special case of Visual
> Studio, where the build system, the project manager and the compiler
> are so tied together that it makes it really hard to use the VS build
> system to compile using any other compiler, and vice-versa. Which is
> why it is mentioned in the generator documentation.

If any generator can launch any compiler what is the point of choosing a
generator ? Is it just that the end-user knows which generators exist on
his system ? I would think that generators are just in artefact and you
should only need to tell CMake that you want to use some command for
compiler and perhaps an alternate command for linker and other tools you
need and CMake would just choose a generator it can find on your system
and go from there.

Programmers think in terms of 'what compiler and/or other tools do I
need to build some software'. This whole business of generators is a
CMake invention, which should have been merely a CMake internal detail.
If CMake were truly what it no doubt wishes itself to be, it could
simply take the tools you specify, find internally a generator which
could use those tools, create its files, and then tell you to use CMake
--build to build your project and CMake --test to test your project etc.
etc. Instead the docs give you all this information about generators, no
immediate information about how you specify the compiler and any other
tools you need on the CMake command line, and expects that to satisfy
everybody.

>
> I do agree, however, that cmake documentation could largely be
> improved. Good news is that this is actually happening (documentation
> was far worse several years ago, and gets better with every release).

[Peter Dimov via Boost]

Edward Diener wrote:
> If any generator can launch any compiler what is the point of choosing a
> generator ?

Again, the initial purpose of CMake was to generate a collection of
Makefiles that comprise "the build system" of the project. Doing this
manually was sufficiently painful that it caused the development of
"meta build systems" such as autotools, premake, CMake, etc.

So the different generators, in CMake, determine what is generated -
a Makefile, a Visual Studio project, an Xcode project, or a build.ninja
file.

CMake originally didn't have a way to build at all. When it generated
a Makefile, you were supposed to use `make` to build; when it
generated a Visual Studio project, you loaded that in Visual Studio in
order to build.

[Andrey Semashev via Boost]

On 5/31/21 9:26 PM, Edward Diener via Boost wrote:
> On 5/31/2021 12:15 PM, Julien Blanc via Boost wrote:
>> Le lundi 31 mai 2021 à 08:13 -0400, Edward Diener via Boost a écrit :
>>>
>>>
>>> My beef is that the CMake documentation does not tell you what
>>> compilers
>>> a particular generator supports, except for the Visual Studio
>>> generators. Period.
>>
>> Because this is an odd question, in a cmake-centric view. Any generator
>> can launch any compiler (any build step) as part of the build process.
>> They're orthogonal concepts. Now there is the special case of Visual
>> Studio, where the build system, the project manager and the compiler
>> are so tied together that it makes it really hard to use the VS build
>> system to compile using any other compiler, and vice-versa. Which is
>> why it is mentioned in the generator documentation.
>
> If any generator can launch any compiler what is the point of choosing a
> generator ? Is it just that the end-user knows which generators exist on
> his system ? I would think that generators are just in artefact and you
> should only need to tell CMake that you want to use some command for
> compiler and perhaps an alternate command for linker and other tools you
> need and CMake would just choose a generator it can find on your system
> and go from there.

I think, there is a use case where the developer generates a Visual
Studio or XCode project with CMake and opens and uses that project in
his IDE to work on the project, including code editing, compiling,
debugging, etc. I think, this kind of workflow was advertised in the
early days of CMake as a feature - write one CMakeLists.txt, use that to
work on your project from whatever your favorite IDE. I'm not sure how
relevant it is today.

This isn't as much of a feature when you have an IDE that can work with
CMake natively, or when you generate something low level like a Makefile
or a Ninja script. In this case, the generated files are pretty much the
cached result of a configure step (as a somewhat close analogy,
Boost.Build generates project-cache.jam). It's just in the form of
generated Makefiles CMake also caches the tree of build targets, which
Boost.Build has to generate every time you run it, which has a
noticeable delay.

> Programmers think in terms of 'what compiler and/or other tools do I
> need to build some software'. This whole business of generators is a
> CMake invention, which should have been merely a CMake internal detail.
> If CMake were truly what it no doubt wishes itself to be, it could
> simply take the tools you specify, find internally a generator which
> could use those tools, create its files, and then tell you to use CMake
> --build to build your project and CMake --test to test your project etc.
> etc. Instead the docs give you all this information about generators, no
> immediate information about how you specify the compiler and any other
> tools you need on the CMake command line, and expects that to satisfy
> everybody.

The CMake ability to build and test is a relatively recent addition.
Originally, it really was a tool to generate a project for your favorite
build system from a common description and nothing more. It really was
*not* a build system, but a *meta build system*, if you like. So, the
question you would ask was how to use CMake to generate your IDE
project, and the tool selection was mostly deferred to the IDE, where
possible. Of course, it didn't work so well in practice because the
generated projects and Makefiles are so very different. Heck, even to
just configure build configuration type (debug/release/etc.) one had to
write two different branches in CMakeLists.txt - one for Makefile-style
build systems and the other for VS-style projects.

Recently, as CMake takes on more and more functionality of a build
system, providing portable ways of interaction with the underlying build
system (and therefore removing the need of interacting with it
directly), providing more portable ways of configuring the build, and as
more and more IDEs integrating with CMake using its API, the generator
stuff is getting mostly legacy. I think, it is currently half way there,
so the kludges that stem from the underlying build system are still
visible to the user, but much of the work can be done through CMake
interfaces exclusively.

[Robert Ramey via Boost]

On 5/31/21 12:12 PM, Andrey Semashev via Boost wrote:

>
> The CMake ability to build and test is a relatively recent addition.
> Originally, it really was a tool to generate a project for your favorite
> build system from a common description and nothing more. It really was
> *not* a build system, but a *meta build system*, if you like. So, the
> question you would ask was how to use CMake to generate your IDE
> project, and the tool selection was mostly deferred to the IDE, where
> possible.

This is the way I use it.

Of course, it didn't work so well in practice because the
> generated projects and Makefiles are so very different. Heck, even to
> just configure build configuration type (debug/release/etc.) one had to
> write two different branches in CMakeLists.txt - one for Makefile-style
> build systems and the other for VS-style projects.

I leave things like debug/release unspecified and just switch them in
the IDE.

> Recently, as CMake takes on more and more functionality of a build
> system, providing portable ways of interaction with the underlying build
> system (and therefore removing the need of interacting with it
> directly), providing more portable ways of configuring the build, and as
> more and more IDEs integrating with CMake using its API, the generator
> stuff is getting mostly legacy. I think, it is currently half way there,
> so the kludges that stem from the underlying build system are still
> visible to the user, but much of the work can be done through CMake
> interfaces exclusively.

Actually, from my standpoint, the IDE generation is the only actually
useful feature of CMake and the only reason I added it to my projects a
few years ago. If they stop supporting this, I'll just drop it.


Robert Ramey

[Andrey Semashev via Boost]

On 5/31/21 11:19 PM, Robert Ramey via Boost wrote:
>
> Actually, from my standpoint, the IDE generation is the only actually
> useful feature of CMake and the only reason I added it to my projects a
> few years ago.  If they stop supporting this, I'll just drop it.

If they did, would it really matter, provided that your IDE can open
CMakeLists.txt directly by then? Not that I think they will drop
generators any time soon.