On Sun, 2017-06-25 at 13:35 -0400, Stefan Seefeld wrote:
On 24.06.2017 13:12, P F wrote:
On Jun 24, 2017, at 12:02 PM, Stefan Seefeld via Boost
mailto:boost@lists.boost.org> wrote: While I can see that some people would like the extra control that provides, I also see lots of problems with this approach. (And the fact that some of Boost is header-only is entirely irrelevant to my argument. If there is nothing to build there is nothing to build.)
Both school of thoughts are in disagreement about how to build their dependencies, and believe the other school of thought has lots of problems. Rather than boost try to pick just one(and alienate the other users), with cmake we can easily support both scenarios.
That's an illusion. My point is precisely that we can't "easily support" both, as it requires from all maintainers to understand all the build infrastructure.
It doesn't. The point is the authors has a standalone build that gets its dependencies through `find_package`. The superproject integrates these into a single build with `add_subdirectry` and it overrides `find_package` to make it a no-op. Of course, having our own set of cmake modules would be even better, as it can help provide easier support for the boost workflow(ie generating -config.cmake files), and it can help prevent authors from doing things that work in a standalone build, but not in superprojects(ie using `include_directories` instead of `target_include_directories`).
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.