Re: [boost] cmake target and binary name mangling

Subject: Re: [boost] cmake target and binary name mangling
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-07-23 17:36:53

>> So, all in all, very like Boost.Build currently does. And that's
>> because it's the correct design and approach to take. So we should do
>> that in any cmake of Boost too.
> 
> I'm not necessarily arguing against that approach, but after having
> heard many (both over the years, and recently) argue that CMake's "one
> build directory per configuration" philosophy is better than
> Boost.Build's multiconfig philosophy, it's amusing to see you suggest
> that idiomatic and modern CMake 3 is a reinvention of Boost.Build. :-)

Boost.Build has the correct design. That was and never has been in doubt.

We should not throw out the baby with the bathwater in any cmake
transition. Cleave as close as is possible to Boost.Build and the
existing build and test design. Makes for much less work.

Besides, the "one build directory per configuration" really refers to
differing compiler versions, differing 32 vs 64 bit, and the other
things for which cmake specifically requires a separate build directory
each. If cmake doesn't require a separate build directory for something,
then use graphs of targets.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/