Re: [boost] CMake, modular Boost, and other stories

Subject: Re: [boost] CMake, modular Boost, and other stories
From: Mike (mike.dev_at_[hidden])
Date: 2019-04-24 07:12:08

   > Hmmm - so no boost library should include any
   > other boost library? Does  that seem a good idea?
   Please don't put words in my mouth. I didn't say that
   and you know it. But the dependency graph could
   easily be significantly simplified once c++03 is no
   longer a concern. Again: I'm talking about the
   future, not the current state.
   Just an example: [1]Boost.TypeErasure depends on
   [2]Boost.Thread(and all that entails), just because
   somewhere in its bowels it needs a mutex.
   > It's always been good practice to not repeat/copy
   > functionality in one library into another.
   Not always. A recent example I stumbled over:
   Boost.Signal2 depended on boost multi index (which
   itself depends on a lot of other libs) because it
   reused it's scope guard implementation
   (IIRC about 50 lines of straight forward code).
   Tying yourself to another library for something
   trivial like that should not be a no-brainer.
   > 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.
   So boost should not only get its unique build system, but also its
   unique dependency management tool?
   I can tell you as a user: Thanks but no thanks.
   Also: Didn't you forget source files somewhere in
   there? What about tests?
   Bottom line: If boost as a whole was developed as a single project with
   some coordinated devlopment
   goal and strategy , it would make sense to distribute
   it as a single package/framework and a single
   cmake config file. It seems to me however, that it
   is more a (huge) collection of independently
   developed libraries, so I think it is more appropriate
   to treat them as such, even if there is a huge amount
   of coupling between them.

   Am 23.04.19, 23:56, Robert Ramey via Boost <boost_at_[hidden]>
   schrieb:

     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
     _______________________________________________
     Unsubscribe & other changes:
     [3]http://lists.boost.org/mailman/listinfo.cgi/boost

References

   1. http://Boost.TypeErasure/
   2. http://Boost.Thread/
   3. http://lists.boost.org/mailman/listinfo.cgi/boost