Re: [boost] Status of the CMake-ification

Subject: Re: [boost] Status of the CMake-ification
From: Alex (alex.staticlibs_at_[hidden])
Date: 2015-11-17 12:24:52

Hi,

On 11/17/2015 04:17 PM, Robert Ramey wrote:
> On 11/17/15 12:37 AM, Stephen Kelly wrote:
>> Louis Dionne wrote:
>>
>>> Dear Boost,
>>>
>>> I'd like to inquire about the status of the CMake-ification of Boost
>>> that
>>> had
>>> been started a while ago. AFAICT, the effort is completely stopped
>>> now; is
>>> this correct?
>>
>> Yes. It can never reach a completeness because the Boost community
>> doesn't
>> want it, so the effort stopped.
>>
>> Note that for users of boost, there would be a great benefit if
>> boost.build
>> would generate cmake packages with imported targets. Keeping
>> boost.build and
>> generating such files (as Qt does with qmake) could be an alternative
>> area
>> to make effort in and would provide more benefit in the shorter term
>> for all
>> external users of boost+cmake.
>>
>> I can help if someone who maintains boost.build wants to pursue that.
>>
>>> Also, I'd like to poll the community to gauge interest in the rebirth of
>>> such
>>> an effort. __I'm not proposing myself to work on such a rebirth__,
>>> but I'm
>>> just curious to know what the community thinks about it. I, for one,
>>> would
>>> love to see it happen.
>>
>> It can be revived at any time if there's a decision and a plan to
>> complete
>> it.
>
> I was present at the creation and demise of the CMake effort.  It has a
> lot of resources behind it.  It's my belief that it was unsuccessful
> because it failed to appreciate the way boost works.  (Ironic I know). I
> believe that if you want to make a change in Boost, the most effective
> way is to work from the bottom up.  In this case this means encouraging
> individual authors to include CMake files for their projects.  These can
> easily coexist with the bjam projects.  And boost doesn't have means to
> prohibit authors from doing this.  If you convince enough authors to do
> this - perhaps providing help for them - or documents or whatever,
> someone will then raise the question - why doesn't everyone do this?  Of
> course then the usual brohaha will ensue - that's what we do.  But the
> upshot will be someone will come up with a script which will walk
> through all the boost libraries and invoke just the CMake build - or
> maybe CMake if there is one and Bjam if there isn't or .... - I don't
> know.  Eventually we could get to the place where the documentation is
> now.  There is wide variety that has come about as fashions change but
> it seems to work OK.   Personally, I don't see any reason why each
> library can't select it's own build system as it currently selects it's
> own documentation system.  Basically, these ideas are demonstrated and
> promoted with the Boost Library Incubator.
>
> To summarize, individual authors are free to support CMake if they want
> and you're free to encourage and help them to do so.  Even if you don't
> get every library on board - you'll still be making progress toward you
> desired goal - so have at it!
>
> BTW I'm willing to accept contributions to the boost library incubator
> which expand upon the topics there.
>

I was doing a bunch of work composing existing (non-Boost) CMake 
projects to be used as "submodules" in multi-module projects. I found 
that most CMake projects in the wild are almost impossible to compose if 
they weren't written with the composeability in mind from the start. 
Stuff like silently rewriting flags, changing output dirs, rewriting 
files in source dir (zlib is doing so) etc prevents the reuse. I ended 
up using new custom CMake scripts (based on existing CMake scripts, with 
the obvious burden to maintain them) for most of the projects.

Just my 2 cents.

-- 
-Alex