On Wed, Sep 26, 2018 at 5:02 PM Raffi Enficiaud via Boost < boost@lists.boost.org> 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.