Boost.URL as subproject should not automatically add dependencies

[alandefreitas]

https://github.com/boostorg/cmake#using-an-individual-boost-library-with-add_subdirectory documents a workflow to include individual Boost libraries with add_subdirectory. The workflow works by extracting all transitive dependencies with boostdep and including each of them as a subdirectory.

This workflow is used by other Boost libraries by Peter, libraries whose CMake scripts were generated by boostdep, and is also used as an example in boost-ci:

• https://github.com/boostorg/smart_ptr/blob/763c7f56cde9d029233cb03d574bc7e2b9e8864d/test/cmake_subdir_test/CMakeLists.txt#L9-L16
• https://github.com/boostorg/boost-ci/blob/master/test/cmake_test/CMakeLists.txt

25 Boost libraries use this pattern when testing the library being included as a subdirectory.

On the other hand, Boost.URL includes its dependencies from the superproject with add_subdirectory when included as a subdirectory. This means anyone else trying to use the pattern above also includes Boost.URL will get an error because they are trying to create targets for some dependencies twice (The existing target is an interface library created in source directory).

Thus, Boost.URL should probably stop including its dependencies so that it's brought into line with how its peers expect it to work.

However, we had a previous problem with the pattern above and we need to consider that in this transition. When transitive dependencies are explicitly listed in cmake_test, it creates errors that are sometimes impossible to fix because transitive dependencies are unstable. For instance,

• Something might pass CI in develop but fail when it's pushed to master because the transitive dependencies are different there.
• The transitive dependencies might even change while we are still working on the problem.
• New commits a few weeks after the previous commit almost always need to include another commit updating the list of dependencies.
• It also causes problems in the other direction: listing too many dependencies is also a problem because it'll be trying to include a library depinst.py didn't clone.

The reason most libraries that use this pattern haven't been having a problem with this seems to be that they are almost exclusively libraries that have been stable for a long time and have almost no transitive dependencies. Most are <= level 2 in terms of dependencies. The highest-level library there is Boost.Regex (level 6) whose 6 transitive dependencies are unlikely to change.