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. 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. 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.
Raffi