Re: [boost] Fw: Interlibrary version cchecking

Subject: Re: [boost] Fw: Interlibrary version cchecking
From: David Abrahams (dave_at_[hidden])
Date: 2010-10-18 13:03:42

At Mon, 18 Oct 2010 09:05:15 -0800,
Robert Ramey wrote:
> "Robert Ramey" <ramey_at_[hidden]> wrote in message
> news:<hsdfuq$prj$1_at_[hidden]>...

> > Turns out that the idea of a single boost library deployment has
> > come up a couple of times here at BoostCon 2010.  While preparing
> > my presentation I considered the problem of what would happen if
> > one installed one library which depended on an newer version of a
> > different library than the user already had installed.  I actually
> > woke up in the middle of the night imagining someone would ask
> > about that during my talk.  I puzzled about it
> 
> > for some time and the day before I found a way to address it - in my own 
> > mind at least.  It also seems that it turns out that there are tools that 
> > can also manage this.
> > 
> > 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.
> > 
> > Basically each library includes a file "manifest.hpp".  This gets
> > included when any header gets included (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.  I just verified
> > that the code compiles so at this point it's only an idea.
> 
> > 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.

Seems like you need something like this somewhere.  Whether belt and
suspenders are needed or not is open to debate I suppose.  If you
think your source code will be used outside the environment of any
given tool, it's probably a good idea to have these internal checks.
One issue, of course, is that some library dependencies aren't Boost
libraries, and they have (or don't) their own way of indicating their
version.  Your scheme seems a lot more complicated than industry
standard practice, which is to use one or two long integer constants
as macros (c.f. __GCC_VERSION__ and friends).  That's also useful for
#ifdefing, whereas mpl::int_<>s are not.

> #ifndef BOOST_ITERATOR_MANIFEST_HPP
> #define BOOST_ITERATOR_MANIFEST_HPP
> 
> // MS compatible compilers support #pragma once
> #if defined(_MSC_VER) && (_MSC_VER >= 1020)
> # pragma once
> #endif
> 
> /////////1/////////2/////////3/////////4/////////5/////////6/////////7/////////8
> // manifest.hpp: Verify that all dependent libraries are at the correct
> // versions
> 
> // (C) Copyright 2010 Robert Ramey - http://www.rrsd.com . 
> // Use, modification and distribution is subject to the Boost Software
> // License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at
> // http://www.boost.org/LICENSE_1_0.txt)
> 
> #include <boost/mpl/int.hpp>
> 
> namespace boost {
> namespace iterator {
> 
> class manifest {
> public:
> 	// specify the current version numbers for this library
> 	typedef boost::mpl::int_<2> interface_version;
> 	typedef boost::mpl::int_<3> implemenation_version;
> };
> 
> } // serialization
> } // boost
> 
> #endif // BOOST_ITERATOR_MANIFEST_HPP

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com