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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk