Re: [boost] [cmake] Pull request announcement

Subject: Re: [boost] [cmake] Pull request announcement
From: Roberto Hinz (robhz786_at_[hidden])
Date: 2018-09-26 20:56:31

On Wed, Sep 26, 2018 at 5:02 PM Raffi Enficiaud via Boost <
boost_at_[hidden]> wrote:

> On 26.09.18 21:49, Edward Diener via Boost wrote:
> > On 9/26/2018 2:29 PM, Raffi Enficiaud via Boost wrote:
> >> On 26.09.18 20:09, Stefan Seefeld via Boost wrote:
> >>> On 2018-09-26 01:59 PM, Raffi Enficiaud via Boost wrote:
> >>>
> >>>>
> >>>> * create a cmake build tree only for a subset of boost. Say you want
> >>>> to compile only library X that depends on other libraries Y and Z,
> >>>> and only X,Y and Z will be added to the cmake project. This is
> >>>> already in place.
> >>>> * create a stub from cmake that automatically checks out the
> >>>> required dependencies. This needs to be added, but should be easy to
> >>>> do.
> >>>>
> >>>> Is this second use case a good scenario for you?
> >>>
> >>> A use-case I'd like to see supported:
> >>>
> >>> * allow an individual project to be built against prerequisite boost
> >>> libraries that are pre-installed on the system (no matter whether
> >>> that installation was done manually or using some system package
> >>> management, as is common on Linux).
> >>>
> >>> This is a precondition for considering Boost project repos as truly
> >>> independent, as the two use-cases you suggest above would still imply
> >>> a dependency on the source repo level, rather than the package level.
> >>>
> >>
> >> I am sure if I dig deep in the mail archive, I will find some details
> >> about what you need, right now it is not very clear to me.
> >>
> >> So, is this what you want:
> >>
> >> 1. you do eg a sudo apt-get boost-X
> >> 2. you clone boost-Y that requires boost-X
> >> 3. you develop your local clone of boost-Y that links to boost-X
> >> installed on your system
> >>
> >> Is that what you are describing? If not, you can stop reading...
> >>
> >> In that case, we need a versioning.
> >> But I believe this is a bad practice. I do not know if I should
> >> elaborate...
> >>
> >> IMO it will make the life of developers really hard for the following
> >> reasons:
> >>
> >> 1. First of all, the dependencies change over time: for the system
> >> libraries you would have for instance X<-Y<-Z and for the local clone
> >> you may have X<-Q<-Z. This ends up in weird scenarios: you checked out
> >> only Y and Z, but you need Q and not Y.
> >> 2. Imagine you have for library X<-Y<-Z again, and you work on X and
> >> Z. You may have then 2 copies of "Z" (system + clone) with different
> >> versions. We can say that one takes precedence over the other one, but
> >> still you will end-up in an inconsistent chain of dependencies, and
> >> the developer can silently source/link the wrong "Y" or "Z" ("Y" on
> >> system links to user "Z", etc)
> >>
> >> The root of the problem with such an approach is that the user and
> >> system packages are interleaved, while there should be only one arrow
> >> on the dependencies: user clone should depend on system installation,
> >> system installation should never see user clone.
> >>
> >> The benefits of having a full clone (or a consistent subset) are much
> >> higher.
> >
> > It can work without versioning when you have library X which depends on
> > library Y, and both libraries come from Boost 1.xx, and no other library
> > X or library Y can be picked up at either the compilation, and/or
> > linking, and/or run-time phase.
>
> Or even at setup before build phase. I am a small step behind the
> cmake -DWITH_TEST=ON -DAUTO_CLONE_DEPENDENCIES=ON $boost_folder
>
> You do not need a full clone, just a consistent subset that is being
> pulled from what you need. And this should work.
>
> ... but here, you have indeed an implicit versioning that is the current
> repo or superproject GIT version/hash. You want library X checked out
> from rev R of the superproject. You will clone all the dependencies of
> libX that were at the same rev R of the superproject (or higher,
> actually I do not know...).
>
> > But what happens when you have library X
> > from Boost 1.xx and library Y from Boost 1.yy ? There is no guarantee
> > that they will work together without some sort of versioning system.
>
> This is also what I am saying, I believe we agree on this.
>
> > Add
> > to that the fact that the placement of library X and library Y may be
> > anywhere on the end-user's hard drive, and that that their may be
> > multiple releases of library X and library Y in different places on the
> > end-user's hard drive, and that a typical dependency graph involves much
> > more than just library X and library Y; I do not think such a realistic
> > scenario can possible work without some sort of versioning system.
>
> Exactly. And even with packaging tools such as pip, brew or conan, this
> causes some headaches sometimes.
>

Hi all,

I also agree that mixing a libraries from boost 1.xx with boost 1.yy
should simply be discouraged.
I also find promising the idea of making a step before invoking CMake
to configure the modules. Supose one wants to build the libraries
xxx and yyy:

# step 1
# get boost root
git clone -b develop https://github.com/boostorg/boost.git boost-root
cd boost-root

# step 2
# Execute a script that executes `git submodule init ` for
# libs/xxx, libs/yyy and all submodules that they depend on:
./init_submodules_dependencies.sh libs/xxx libs/yyy

# step 3
# Configure the build system to work only with this modules:
# ( and their dependencies )
./select_cmake_modules.sh libs/xxx libs/yyy

# step 4: use the build system to generate, build, install, test, etc

This looks so simple and effective to me.
Does anyone disagree with this approach ?

Note that instead of step 1 and 2 one could simple download and unpack
the boost tarball.