Re: [boost] [cmake] Pull request announcement

Subject: Re: [boost] [cmake] Pull request announcement
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2018-09-26 20:01:18

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.

Raffi