Subject: Re: [boost] [cmake] Pull request announcement
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2018-09-26 18:52:33
On 2018-09-26 02: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
>>> 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...
It is, exactly.
> In that case, we need a versioning.
You are a couple of steps ahead of me. All I want is to be able run a
build of my project such that it picks up its Boost dependencies from
some other location, no matter how it got there. It may got there by my
running `b2 install` on those prerequisite libs first. Versioning only
comes into it once I want to make claims as to my (Boost) library's
compatibility with those versions of prerequisites. But I'm not even
wanting to make any such claims - yet, I'm only wanting to do a build !
> But I believe this is a bad practice. I do not know if I should
> 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)
Why are you making things so complicated ? Of course, if I have two
versions of library 'Z', I'm entirely on my own as to not mixing them up
in downstream dependencies. But why do we even have to discuss this ?
All I want is the ability to work on a Boost library project, compiling
it against some other prerequisite (versioned) libraries, some of which
may be part of Boost.
None of this is rocket-science, and has been a rather common use-case
throughout the industry. The only "new" thing here is my asking to
consider two Boost libraries as separate entities, rather than the whole
bunch of >150 Boost projects as a single monolithic entity.
And just for avoidance of doubt (and to avoid this discussion going even
deeper into the rat-hole): I'm *not* asking for individual Boost
libraries to follow separate release cycles. But yes, we should also
start talking about versioning as well as backward-compatibility (i.e.,
API and ABI stability). That, too, is a rather common concern in the
industry. It just so happens that Boost has been managing to ignore itÂ
-- ...ich hab' noch einen Koffer in Berlin...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk