Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk