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

From: Nat Goodspeed (ngoodspeed_at_[hidden])
Date: 2006-02-18 13:22:27

> -----Original Message-----
> From: boost-users-bounces_at_[hidden] [mailto:boost-users-
> bounces_at_[hidden]] On Behalf Of David Abrahams
> Sent: Saturday, February 18, 2006 1:02 PM
> To: boost-users_at_[hidden]
> Cc: Hartmut Kaiser
> Subject: Re: [Boost-users] [bcp] [shared_ptr] [wave] Extracting subset
> ofboostforshared_ptr - 3.2MB?
> 
> "John Maddock" <john_at_[hidden]> 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.