Vinnie Falco wrote:

On Thu, May 27, 2021 at 3:05 PM Peter Dimov via Boost 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 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.

Gesendet: Freitag, 28. Mai 2021 um 11:42 Uhr Von: "Niall Douglas via Boost" An: boost@lists.boost.org Cc: "Niall Douglas" 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/2488966ae1faf88f945ae486647b18edebd... So it should probably also directly declare the dependency on Boost::throw_exception in the CML. Mike

Niall

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/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 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 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 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 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 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/39443f18c03c4568fdf75bed3eaa802c26563... 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 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/6047fd69d39a81c4296ba27ee09f22dd0f76... and https://travis-ci.org/github/boostorg/assert/jobs/771973215

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:cma...) 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

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

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

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.

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.

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 ?

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