Re: [boost] CMake Announcement from Boost Steering Committee

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Alain Miniussi (Alain.Miniussi_at_[hidden])
Date: 2017-07-19 16:36:29

On 19/07/2017 18:03, Olaf van der Spek wrote:
> On Wed, Jul 19, 2017 at 5:39 PM, Alain Miniussi via Boost
> <boost_at_[hidden]> 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
> 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.