On Mon, 2017-06-26 at 15:46 -0400, Stefan Seefeld wrote:
On 26.06.2017 13:36, paul wrote:
On Sun, 2017-06-25 at 13:35 -0400, Stefan Seefeld wrote:
It's precisely the lack of encapsulation that causes this overhead. I'd be happy to include additional files in my library if it wasn't for the implied maintenance cost.
Yes, I would like the maintenance cost to be just adding source files to a list somewhere. Of course, for header-only libraries its even easier.
Although, there are libraries like Boost.Python or Boost.Context that have more complicated build infrastructure, but the nice thing about cmake is that there is a much larger community to help with the maintenance cost rather than relying on a few Boost.Build gurus.
That's definitely true. But ultimately, it comes down to the maintainer or the library's own developer community. Whenever users try to build Boost.Python and run into issues, they are submitting issues to *our* tracker, and I hate having to tell them to go ask for help in a different community because I'm unable to help myself.
Not exactly. The user may have a build problem, but the likeliness that they(or another user who is reading the issue) know enough cmake to contribute a fix is very much higher than them knowing enough bjam to provide a fix. Its not that users need to go to another community for help, but that part of the cmake community becomes part of the boost community as well. Furthermore, there is already several boost developers who know and understand cmake that can provide help, so that even if the user doesn't know enough cmake, someone in the boost community does, so we don't need to direct the user somewhere else.