CMake, modular Boost, and other stories
I'm very much in favor of separate packages. James is right, that - at the moment - most boost libraries are so tightly coupled that they can't really be treated as separate libraries, but when changing things it is just as important to ask, "Where do you want to go?" as "where you are now". I for one very much hope that boost (at least the libraries that are actively maintained) will become less coupled in the future, such that when I just want to use library X, the rest of boost doesn't come as a dependency with it. It also fits the management structure (or rather the lack thereof) much better. Also, the mechanisms for modular boost distributons already exist through e.g. vcpkg and conan, so I don't see the problem in also providing independent cmake configfiles. Finally: About how many libraries are we talking here anyway? Only the compiled ones get their separate config file - correct? Best Mike
On 4/23/19 2:28 PM, Mike via Boost wrote:
I for one very much hope that boost (at least the libraries that are actively maintained) will become less coupled in the future, such that when I just want to use library X, the rest of boost doesn't come as a dependency with it.
Hmmm - so no boost library should include any other boost library? Does that seem a good idea? It's always been good practice to not repeat/copy functionality in one library into another. I've said it many times before so I won't make a big deal about it here. But what is really needed - and it may already exist in BCP but hasn't been promoted is a simple tool: a) start with one's application b) run the app through a tool which recurrsively reads headers c) and creates a list of all headers needed d) extract library names from that list e) add the git repo of those libraries to my apps project. I don't seen any way to get around this. And util we can easily do this - boost will not be modular. Robert Ramey
participants (3)
-
Mike -
Peter Dimov -
Robert Ramey