Re: [boost] Fw: Interlibrary version cchecking

Subject: Re: [boost] Fw: Interlibrary version cchecking
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-10-18 17:41:11

Hi Robert,

I don't know if your proposal is the correct way to manage with library dependencies at compile-time and run-time, but what I'm sure is that we need to have the version of the dependant libraries as preprocessor symbols, as we can need to make some adaptation if we compile respect to one version or another.

----- Original Message ----- 
From: "Robert Ramey" <ramey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, October 18, 2010 7:05 PM
Subject: [boost] Fw: Interlibrary version cchecking

> "Robert Ramey" <ramey_at_[hidden]> wrote in message
> news:<hsdfuq$prj$1_at_[hidden]>...
>> It's not that I don't trust tools but I wear a belt AND suspenders.  So I 
>> would like a method which guarentees that when I build one library, I
> don't 
>> accidently include code from a prerequisite library which is a version so 
>> old that things won't work. I would also like to know that I'm not 
>> accidently running with a DLL built with an old version.

Usualy this is managed by the packager of the platform, isn't it?
 
>> Basically each library includes a file "manifest.hpp".  This get's
> included 
>> when any header get's includes (once at most due to include guards).  This
>> includes a static assert that checks that the prequiste libraries are of 
>> sufficiently recent version that a dependent library (or user application)
>> requires.  There is also a manifest.cpp file included in the library which
>> checks any prequiste DLLS.  This would be an exheedingly small overhead to
>> avoid what could be an incredibly large headache.
>> 
>> But it seems that some kind of check like this is un-avoidable of one
> want's 
>> to deploy libraries as needed rather than as a monolithic distribution.
>> 
>> Robert Ramey

I see your proposal as an intrusive workaround for users that don't use the packager of the platform. The thing I don't like is that it forces the dependant libraries to use an homogeneous framework, which usualy will be quite difficult to setup outside Boost. 

This could be done if the proposal is only restricted to see the coherence between a Boost library and its dependants once we start to release the Boost libraries independently, but I would prefer we try to see what we can do using the packager of the platform the time been.

Best,
Vicente