Re: [boost] CMake Announcement from Boost Steering Committee

On 7/18/17 3:52 PM, Tom Westerhout via Boost wrote:

On Jul 19, 2017 12:00 AM, "Robert Ramey via Boost" 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