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]>
>> 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 -
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk