Boost logo

Boost :

Subject: Re: [boost] Lets do 1.70.1 WHO IS WITH ME!!!
From: James E. King III (jking_at_[hidden])
Date: 2019-05-05 16:26:42


On Sun, May 5, 2019 at 12:46 AM Rene Rivera <grafikrobot_at_[hidden]> wrote:
>
> On Sat, May 4, 2019 at 10:00 PM James E. King III via Boost <boost_at_[hidden]> wrote:
>>
>> I haven't seen a comprehensive plan put forth that would lead to
>> modularization.
>
>
> Some of us have worked for years in that direction, without the need for a formal plan. We're actually rather close.
>

To that end I started a discussion on Conan's github issues page to
figure out how one could use it purely to download boost modules (and
all their dependencies), and more importantly how to then use the
downloaded bits with any build system (i.e. should be able to ask
conan, "for this recipe, what are the include paths?", "for this
recipe, what are the library paths and libraries?"). I'm not
particularly interested in using conan as a build and packaging system
for my own projects which already have their own, but to be able to
leverage conan to download pre-built boost moduls and only the ones I
need would be pretty cool. The ability to allow other build systems
to run commands that download and find paths of dependencies would be
really useful but I'm not sure conan does that.

Another concern I have is that dependencies all seem to be manually
managed right now for all of these third party systems. The recent
cmake check-ins I have seen all have a manual set of module
dependencies and I pushed back on this. Conan has their own list of
dependencies; cmake has its own list of dependencies. I believe they
all get their info from boostdep right now, which is good, but I think
it is a manual consumption process for each release. Each boost
repository should be able to automatically advertise the
compile/runtime dependencies as well as the test-only dependencies. I
slapped something together quickly this morning that helps visualize
that (https://github.com/jeking3/boost-deptree), perhaps some of that
type of logic could find its way into b2 so that b2 could
automatically manage direct compile/runtime dependencies and direct
test dependencies inside each project's meta directory? Then cmake,
conan, and whatever else would be able to programmatically consume
that data out of the repository it is trying to package or deliver.

- JIm


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk