Dmitry Arkhipov wrote:
В письме от вторник, 23 июня 2026 г. 20:47:53 MSK пользователь Vinnie Falco via Boost написал:
What I am proposing is that if you have
#include <boost/capy/asio/asio.hpp>
And we somehow inform boostdep that a directory should be ignored:
./include/boost/capy/asio/
boostdep works the way it does because a user's mind also works that way. A user installs a Boost library with its dependencies (using boostdep). The user puts #include <boost/capy/asio/asio.hpp> into his code. Suddenly the user gets compilation errors. The user is now very confused, because he was under impression that he installed required dependencies.
So, just creating an exception for boostdep is not enough, there should be some way to clearly signal to users that the header only works if *additional* requirements are satisfied. I was thinking about this for some time, and maybe we could agree upon header naming scheme for such optionally working headers. E.g. boost/copy/ext/asio.hpp. This signals the "extra" nature of the header to the user. We could then teach boostdep to ignore these headers by default (or vice versa, only ignore them optionally).
The way package managers such as vcpkg handle these cases is by having "optional features" that can be installed separately. If you install `capy`, you don't get Asio support, but if you install `capy[asio]` or `capy+asio` or whatever, you do get it. This is also useful for things like bzip2 or zstd support. Actually, if you install `capy`, you get the default features, which may or may not include `asio`. So you might need to install `capy[]` or `capy-asio` or `capy-core` or whatever to not get Asio support. I'm not at all sure that we need all that complexity.