This is largely directed to John Maddock, the maintainer of config, but of course anyone else can respond who is interested. I have been working to integrate my VMD library, and essentially variadic macro support, into Boost PP, with help and discussion offline of Paul Mensonides. I am now at the testing phase and all is now going well. This is currently being done in a separate library but when Paul and I are satisfied we intend to update the trunk with our changes. The library is at https://svn.boost.org/svn/boost/branches/pplib/variadics. One problem that I have can be explained by the fact that Boost PP currently does not depend on any other Boost library, not even Boost config. The reason for this is that Boost PP has been designed to work with C compilers ( or C++ compilers in C mode ) as well as C++ compilers. This means that the code to detect variadic macro support in Boost is duplicated in two places, both in config, which I basically started with the blessing of John Maddock with the BOOST_NO_VARIADIC_MACROS macro, and in Boost PP in a configuration file which I have coded and essentially duplicates the code in config for variadic macro support. I do not like this. Duplicating functionality in two different places, even as simple as determining variadic macro support for compilers, is error prone and a maintenance problem. Changes in one place have to be done in the other, and this would need to constantly be tracked. My initial thought was to see if config could work with C compilers, but all investigation there has led me to believe that it would be too many unnecessary changes to config, would complicate config greatly, would need extensive testing against all compilers, and that since config is central to all of Boost such a potential massive change to it it is a bad idea. So my current thought is to remove the code in config which tests for variadic macro support for a given compiler, to determine if BOOST_NO_VARIADIC_MACROS should be set, into a separate header file for each compiler which might set BOOST_NO_VARIADIC_MACROS, and then #include that header file in the compiler's header file, at the place where currently the setting of BOOST_NO_VARIADIC_MACROS exists ( or possible at the end ). The separate header file itself for testing variadic macro support is easily C compatible and I could use it in my Boost PP configuration file. This would eliminate duplication of the code to test for variadic macro support in config and Boost PP while keeping the goal of allowing Boost PP to still work with C compilers. Is this possible/desirable as far as config goes ? It would only affect the current code for setting BOOST_NO_VARIADIC_MACROS, hardly a Boost world-shaking event, and can easily be done by me and tested in regression tests. If it is, one further consideration is that the code in the Boost PP configuration file still would have to internally duplicate the checking and order of each compiler in the 'select_compiler_config.h' in config, but this is at least much better, and much less of a maintenance problem for Boost PP, than having to duplicate the code for checking for variadic macro support itself. Even this could be worked around, with a probably undesirable change to 'select_compiler_config.h', which I will proceed to suggest nonetheless. If we could add to that file another set of #defines for the corresponding variadic macro checking header file for each compiler that needs it. Something like: #define BOOST_COMPILER_CONFIG_NVM "boost/config/compiler/somecompiler_nvm.hpp" then in my Boost PP config header file I could go: #include <boost/config/select_compiler_config.hpp> #ifdef BOOST_COMPILER_CONFIG_NVM #include BOOST_COMPILER_CONFIG_NVM #endif and I could then check BOOST_NO_VARIADIC_MACROS and this will work for C compilers ( 'select_compiler_config.hpp' itself has nothing related to C++ and should work with any C compiler AFAICS ). But I would understand that littering 'select_compiler_config.hpp' with another set of #defines just to satisfy my need in Boost PP may not be acceptable to the clean design of that file, even if it would eliminate my need to reduplicate its logic in the Boost PP configuration file for variadic macro support in Boost PP which I have created.