Suppose I'm the user of a class called foo which supports serialization through intrusive methods. So, foo.h will look like: // foo.h #include <boost/serialization/access.hpp> // other, non serialization-related includes class foo { ... }; Now, a programmer uses foo, but does not take advantage of its serialization capabilities. // user.cpp #include <foo.h> // use foo and a second programmer uses foo *and* serializes it. //user2.cpp #include <foo.h> #include <boost/archive/text_oarchive.hpp> // use foo and its serialization capabilities. So far so good. Boost 1.33 release of Boost.Serialization, if I'm not wrong, will include automatic linking, and here comes the problem: when doing the upgrade to 1.33, user2 will be delighted that he'll no longer need to do the linking stuff by himself; but user1 will get mysterious "not found" linking errors, or worse yet, he'll have Boost.Serialization automagically bundled into his final executable, when he never explictly dealed with this lib in the program! Of course, user1 can set BOOST_SERIALIZATION_NO_LIB and be done, but this is a burden which I'd like to save users from, if possible. So, here comes the question. Suppose the implementer of foo changes foo.h as follows (please bear with any preprocessor mistake by my part if there's any, I hope you get the point nonetheless): // foo.h #if defined(BOOST_SERIALIZATION_DYN_LINK) # define BACKUP1 #endif #if defined(BOOST_SERIALIZATION_NO_LIB) # define BACKUP2 #endif #undef BOOST_SERIALIZATION_DYN_LINK #define BOOST_SERIALIZATION_NO_LIB #include <boost/serialization/access.hpp> #if defined(BACKUP1) # define BOOST_SERIALIZATION_DYN_LINK #endif #if defined(BACKUP2) # define BOOST_SERIALIZATION_NO_LIB #endif // other, non serialization-related includes class foo { ... }; Now, if my idea is correct, user1 won't get Boost.Serialization autolinked (since <boost/serialization/access.hpp> was included with BOOST_SERIALIZATION_NO_LIB), and user2 will benefit from autolinking, as he included another Boost.Serialization header on his own. The best of both worlds. Do you think this approach would work? Any foreseeable problem? Thanks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo