Re: [boost] [cmake] Pull request announcement

Subject: Re: [boost] [cmake] Pull request announcement
From: Edward Diener (eldiener_at_[hidden])
Date: 2018-09-26 19:49:54

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