Re: [Boost-users] [bcp] [shared_ptr] [wave] Extracting subset ofboostforshared_ptr - 3.2MB?

-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Saturday, February 18, 2006 1:02 PM To: boost-users@lists.boost.org Cc: Hartmut Kaiser Subject: Re: [Boost-users] [bcp] [shared_ptr] [wave] Extracting subset ofboostforshared_ptr - 3.2MB?

"John Maddock" writes:

...

...

Unfortunately bcp isn't smart enough to not look into optional dependencies that are guarded by #ifdef.

we need a better system. It would be a lot of work, but maybe it would be the first real use of Wave as a library rather than just as a preprocessor. We could use the graph library to do a real search with some knowledge of compiler and configuration #defines.

[Nat] That was my reaction as soon as I first saw John's post "bcp isn't smart enough...": wow, he could use Wave! But I'm confused as to why you'd need the graph library? Wouldn't it work just to point bcp to the compiler of interest -- by giving it the name of one of a set of small prepackaged files that #defines the vendor-specific compiler-predefined macros that Boost cares about -- and let bcp operate on post-Wave, fully-preprocessed source code? Ah: that would actually discard the identities of all the #included files! Sigh. Nonetheless, it feels as if that approach could be tweaked to get much closer to the "I only care about this one compiler" use case than is currently possible.