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