Re: [boost] CMake Announcement from Boost Steering Committee

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2017-07-21 17:31:08

On 21/07/2017 16:25, Roger Leigh via Boost wrote:
> Could I also point to this block in 
> https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindBoost.cmake#L554 
> .  This is what we do in the absence of proper dependency information 
> being provided by Boost, i.e. no pkg-config, cmake config or similar. We 
> hard-code *every* *single* *dependency* from 1.33 up to 1.64 at the time 
> of writing.  I wrote a custom parser to extract this metadata from the 
> autolink information in the headers, similarly to the above ticket. *We* 
> pay the cost of this significant defect in the Boost project in the form 
> of a high maintenance burden and breakage with every new Boost release.  
> Most projects hardcode the information, but it's fragile and should be 
> unnecessary, and so we took on that burden so that CMake users could use 
> Boost without worrying about the problems.  That's why this file is such 
> a huge and over-complicated nightmare.  As and when Boost provides 
> proper configuration information, which I would hope the CMake 
> conversion work would provide, we can throw this entire monster in the 
> bin (most CMake Find modules are a couple dozen lines at most; this one 
> is just shy of 2000).

Then this is a different problem from the build system. You hope the new 
build system will offer a better dependency information for packaging, 
but if Boost.Build experts are not too annoyed, I think we can get this 
much much faster than porting to CMake. People using different build 
systems than CMake could benefit from this, so we're improving the life 
of the 100% of Boost packagers.

So while we are moving to CMake (if that happens because we find enough 
people to do the work), which can take several Boost releases, we could 
kindly ask Boost.Build experts to export that information in a 
compatible way with the most popular packaging systems.

> [...]
> 
> I hope the above isn't too upsetting or controversial.  I wanted to 
> provide some perspective from the point of view of an outsider and end 
> user, and potential contributor, about what things are like from the 
> other side.  Boost is a wonderful collection of libraries, but there are 
> some key things which could be improved, and Boost.Build/b2 has I am 
> sorry to say been one of the worst aspects of Boost.  End users need to 
> go through some pain to work around defects in Boost.Build, as well as 
> Boost.Build doing things differently to most other build systems.  Some 
> might be due to my Boost.Build inexperience, but either way this is what 
> non-experts experience.  It makes using Boost unnecessarily painful and 
> difficult.

I think this is a very valuable information. The SC has given a 
direction, I don't see fixing "annoying" Boost aspects goes against that 
direction.

Best,

Ion