Re: [boost] CMake Announcement from Boost Steering Committee

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-07-18 23:05:01

On 7/18/17 3:52 PM, Tom Westerhout via Boost wrote:
> On Jul 19, 2017 12:00 AM, "Robert Ramey via Boost" <boost_at_[hidden]>
> wrote:
>>
>> On 7/18/17 2:18 PM, Ion Gaztañaga via Boost wrote:
>>>
>>> On 18/07/2017 20:08, Louis Dionne via Boost wrote:
>>>
>>>> (2) Prospective Boost developpers are sometimes driven away from
>>>> submitting because they would have to use Boost's build system, which
>>>> they don't know.
>>>>
>>>
>>> I don't think a C++ programmer with a programming level to write a
>>> Boost library would have any problem to write a Jamfile copy-pasting
>>> from any library.
>>
>>
>> LOL - as such a programmer I can tell you you're wrong!  I don't think
>> you can make a working Jamfile by cutting and pasting.  I have to go
>> back to the bjam documentation and then almost always post a question on
>> the list.  Bjam may have it's advantages - but simplicity, transparency
>> and ease of use are not among them.
> 
> I'm just a GSoC student, so I don't really fit the "Boost library
> developer" profile... Anyway, I had to use either CMake or Boost.Build to
> build and run some tests, and because I had no experience with either, and
> Boost.Build seemed more boost'y, I went for it. So I've just had an
> experience learning to write Jamfiles, and I'd argue that it's not that
> difficult, for a _basic_ case. I.e. as long as you don't need to your own
> target types and generators, you're fine.
> 
> It all goes wrong when you need more "advanced" stuff. I think it's cost
> me approximately 30 hours in total of browsing through docs and source
> code before I've begun to understand how things work. I still don't
> understand the pro topics though.
> 
> It seems to me like there's just not enough documentation/examples. And I
> understand that it's terribly boring for advanced users to write the docs
> because this stuff is obvious for them, and impossible for newcomers
> because they don't understand it themselves. But, I guess, it's a quite
> common situation. And, as usually, the efforts should be combined, i.e.
> someone tries to learn Boost.Build, writes down all his questions while
> gurus help him find and write down the answers. And we obtain nice docs in
> the end. I'd even be willing to volunteer for the padawan's position
> (after GSoC though).
> 
> The point I'm trying to make here is that some non-radical changes might
> be enough to solve the problems Louis has outlined (second one at the very
> least, and as some people have indicated CMake might not help with the
> first one either). And trying them out will probably take much less time
> than the transition to CMake, so why not try the fast & easy path first?
> 

I pretty much agree with this assessment.  It starts out simple, but 
then you need to make something a little bit fancier and then ....

I think bjam could be made much better with relatively few changes.  The 
documents are actually quite good. I know this as I had to plow through 
them for the Nth time the other day.  A large part of the problem is 
that there is too much implicit behavior to actually documentation which 
is fine when things "just work" but then - ....

I and others have been complaining about this for many years.  No action 
has been taken.  Maybe it's not doable, or maybe it's a thankless task 
which is not exceeding tedious for the people who are actually capable 
of addressing this.  I don't know.  But now we've come to this. 
Hopefully we can slog through this without getting lost in the weeds - 
we'll see.

Robert Ramey