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

"Nat Goodspeed" writes:

...

-----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?

It's a graph search problem. You could code it by hand instead of using the graph library (and make mistakes) if you really want to ;-)

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.

Also, there are macros introduced by Jamfiles and configuration macros set by users in their own Jam/Make/whateverfiles. Unless you know what their values will be ahead of time, you may leave out some files the user will need. -- Dave Abrahams Boost Consulting www.boost-consulting.com