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: Boost.TypeErasure depends on
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
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]>
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?
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
But what is really needed - and it may already exist in BCP but
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
- boost will not be modular.
Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk