$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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