Subject: Re: [boost] [cmake] Pull request announcement
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2018-09-26 18:29:57
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
>> * 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
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