Re: [boost] CMake Announcement from Boost Steering Committee

On 19/07/2017 18:03, Olaf van der Spek wrote:

...

...

MSVC

b2 -j12 toolset=msvc-7.1,msvc-8.0,msvc-9.0,msvc-10.0,msvc-11.0,msvc-12.0,msvc-14.0,msvc-14.1 variant=debug,release address-model=32,64 debug-symbols=on

MINGW

b2 -j12 toolset=toolset=gcc-3.4c++03,gcc-4.1c++03,gcc-4.2c++03,gcc-4.3c++03,gcc-4.4c++03,gcc-4.5c++03,gcc-4.6c++03,gcc-5.3c++03,gcc-6.1c++03,gcc-6.2c++03,gcc-6.3c++03 variant=debug,release address-model=32 debug-symbols=on

Not to mention link=static,shared runtime-link=static-shared, and all possible combinations. B2 compiles and executes it really fast.

My question as a Boost developer is, can CMake do the same with similar performance (time/memory/disk,etc.)? I do not know what are the performances with bjam, I just create one build tree (outside of the source tree) per variant, configure once for each variant and then iterate over the build directories. I want to keep the build trees and I want to launch different variants build/texts on different nodes, so the trees need to be separate anyway. So it does take some space since I do not delete the build tree (that is, I choose to keep the object files, I do not know if your technique does the same). But I want to be able to go into the directory of combination X's build when things go wrong anyway. But my variants includes properties (if that the term used to designate toolset, variant etc..) that are not anticipated be bjam. Each MPI implementation correspond to a specify project-config.jam file (sometime simple, sometime not), so I am not sure how I could iterate over intel-mpi-5.0.1,open-mpi-1.6.2, etc... basically, I need to check how it works with different versions/vendor.configuration of an external tools. So in addition to cmake we need scripts to create all those build

On Wed, Jul 19, 2017 at 5:39 PM, Alain Miniussi via Boost wrote: directories and to actually run all those builds? And every project using cmake has to bring their own version of those scripts? Only if you want to use that technique, which I find convenient (and which I cannot use with bjam, so I need to override the previous build for each configuration, cannot run in parallel on different nodes, unless have one git clone per flavor). Right now, with bjam, those libs (the one requiring such tunning) are basically not tested by default. It's not one per project, it's one. And those script/config are likely to be platform specific, they're would be certainly no much point in sharing the specificities of the platforms I use.