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