id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
12328,Clarify which Boost Config headers should not be included directly,Tony Lewis <tonyelewis@…>,John Maddock,"In ticket:12142#comment:1, johnmaddock says:


> No way should optional be including an internal Config header directly - that's just not supported.


So which headers are considered part of Boost Config's public interface? Just `boost/config.hpp`? At present, many other `boost/config/` headers are included by other Boost libraries :

{{{
<boost/config/abi_prefix.hpp>        : archive, chrono, filesystem, iostreams, log, serialization, system, thread, timer, archive, chrono, filesystem, iostreams, log, serialization, system, thread, timer
<boost/config/auto_link.hpp>         : archive, atomic, chrono, container, context, coroutine, coroutine2, date_time, endian, filesystem, iostreams, locale, log, math, mpi, program_options, python, random, regex, serialization, signals, system, test, thread, timer, type_erasure, wave
<boost/config/no_tr1/cmath.hpp>      : accumulators, date_time, functional, gil, graph, interprocess, math, numeric, pending, random, spirit, test, tr1, units
<boost/config/no_tr1/complex.hpp>    : math
<boost/config/no_tr1/functional.hpp> : function, smart_ptr
<boost/config/no_tr1/memory.hpp>     : get_pointer smart_ptr
<boost/config/no_tr1/utility.hpp>    : fusion, tr1
<boost/config/requires_threads.hpp>  : thread
<boost/config/suffix.hpp>            : optional
<boost/config/warning_disable.hpp>   : icl, system, timer
}}}

If Boost Config has internal implementation headers, which users shouldn't directly include, please can they be put into a separate `detail` sub-directory to make this clear?
",Feature Requests,closed,To Be Determined,config,Boost 1.61.0,Problem,fixed,"header,detail,dependency,implementation,interface,optional,config",John Maddock