Re: [boost] Checking library binary compatibility with respect tocompile time options [repost\

Subject: Re: [boost] Checking library binary compatibility with respect tocompile time options [repost\
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-08-05 13:05:11

I notice that the link I sent to a respond to the above didn't handle the 
attachments well. So here they are again.

Robert Ramey

Original post from back in may

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

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.

FYI - no one asked me about this problem at my presentation.  Add one more
confirmation of Murphy's law.

Robert Ramey