John Maddock wrote:
Unfortunately bcp isn't smart enough to not look into optional dependencies that are guarded by #ifdef. In this particular case it follows the dependency to detail/quick_allocator.hpp, which in turn brings in the type_traits and mpl libraries. But quick_allocator.hpp is only used if you #define BOOST_SP_USE_QUICK_ALLOCATOR.
Peter, this comes up so often, I wonder is it worth while "hiding" that optional dependency behind a #define, as in:
#define BOOST_SP_QA <some-header.hpp>
#ifdef BOOST_SP_USE_QUICK_ALLOCATOR #include BOOST_SP_QA #endif
Of course I have no data on how often that dependency is actually needed (or not).
How about something along the lines of: bcp boost/shared_ptr.hpp --exclude=quick_allocator.hpp Or: #ifdef BOOST_SP_USE_QUICK_ALLOCATOR //@bcp optional "quick_allocator is only used if explicitly requested" #include <boost/detail/quick_allocator.hpp> #endif which would then inform the user that an optional dependency wasn't being followed (if this is the default): bcp: an optional dependency isn't included in the subset because `quick_allocator is only used if explicitly requested' bcp: use `bcp boost/shared_ptr.hpp boost/detail/quick_allocator.hpp' to include it The advantage is that we don't have to decide whether to follow a particular dependency, the choice can be left to the person running bcp.