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.

Yes, it's a hard problem to solve accurately, the more you prune the include-tree the greater the likelyhood of the system becomming unreliable. Lets give Peter's suggestion a try and see what it gains us first. John.

"Hartmut Kaiser" writes:

Nat Goodspeed wrote:

...

...

...

...

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.

Some minor comments:

a) Wave can be used to get all the names of the included files directly. b) It's probably better to use configuration files containing the defines, these are treated as command line arguments then. c) As Dave said, there are macros defined in the Jamfile which are difficult to extract properly without support for Wave in the build system.

And there are other macros that will be in system headers potentially not available where bcp is being run, etc. That's why I think it's probably not possible to do a deterministic preprocessing run and capture everything you need.

But generally I like the idea of putting Wave into something useful for Boost itself and will happily help to make that happen.

To be perfectly honest, I can't drive this effort. I can offer algorithmic input and maybe even write some graph search code if it's needed, but someone else will have to take the lead. I hope that's you, Hartmut. -- Dave Abrahams Boost Consulting www.boost-consulting.com

John Maddock wrote:

...

a) Wave can be used to get all the names of the included files directly.

Good, but what would be needed is a sort of tri-state for each define: defined/not defined/maybe defined.

This one is easy. Just run the tool twice, once with the macro defined and once without. Regards Hartmut

An obvious example would be threading macros: if the compiler is in multithread mode different headers may get picked up than in single threaded mode, so "Give me the headers used by msvc" would actually only pick up the headers used under certain circumstances otherwise. Other examples would be substitute std libs, and other "hidden" preprocessor paths taken as a result of macros set by specific compiler options.

John.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

"John Maddock" writes:

...

This one is easy. Just run the tool twice, once with the macro defined and once without.

Not if there's more than one of them: it becomes a 2^N problem.

Oh far, more than that. Consider something like: -DBOOST_MPL_MAX_SEQUENCE_LENGTH=40 The value of this macro affects which headers get included. -- Dave Abrahams Boost Consulting www.boost-consulting.com

"Hartmut Kaiser" writes:

David Abrahams wrote:

...

...

...

This one is easy. Just run the tool twice, once with the macro defined and once without.

Not if there's more than one of them: it becomes a 2^N problem.

Oh far, more than that. Consider something like:

-DBOOST_MPL_MAX_SEQUENCE_LENGTH=40

The value of this macro affects which headers get included.

But this particular macro is application specific, ergo should be constant for all different compiler configurations. The problematic part are the compiler dependent config macros, IMHO.

User configuration info counts too, as we saw with BOOST_SP_USE_QUICK_ALLOCATOR. -- Dave Abrahams Boost Consulting www.boost-consulting.com

David Abrahams wrote:

...

...

Good, but what would be needed is a sort of tri-state for each define: defined/not defined/maybe defined.

This one is easy. Just run the tool twice, once with the macro defined and once without.

No, the combinatorics make that intractable. And you want to re-use common state (when two different settings of a macro leave you with most of the same preprocessor state).

Good point. Regards Hartmut