Re: [boost] [cmake] Pull request announcement

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 
>>> 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...

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 
> 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)

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  
so far.

Stefan

--
       ...ich hab' noch einen Koffer in Berlin...