Dependency reduction

[nealkruis]

Forgive me if this has already been discussed before, but one of my biggest challenges with the geometry library is that it depends on a lot of accessory boost libraries. I am not very familiar with all these dependencies, but several of them appear related to "recent" (e.g. at least since C++14) additions to the C++ Standard, and I imagine they could be replaced with standard library functionality.

I imagine many of them are needed to support code bases that are stuck on earlier versions of the Standard, but I'm curious if anyone (maybe on a separate fork?) has looked into removing the other boost dependencies and making geometry a more self-contained library.

[barendgehrels]

Many dependencies are not real dependencies. For example Boost::polygon, we don't depend on it. But there is an optional adaptation for it. Normally it's never used.

This CMake list is automatically generated, and therefore it picks up these dependencies.

Having said that, we could manually update this CMake list, of course, and we probably should.
Also we could remove some dependencies such as on Boost::tuple and replace them by the standards.
There are also dependencies which are used for the spatial index, but not elsewhere (such as Boost.serialization). That might be finetuned in the CMake lists.

[awulkiew]

Serialization is optional as well.

[vissarion]

I am not against the manual update of CMakeList.txt but I think it is simpler to generate it automatically. Also if new dependencies are added then this is tracked by the generation script. For example, this PR #1122 updates the script to add new dependencies. If we want to remove dependencies from the library then we can remove them and then simply rerun the cmake generation script (this could even automated in github actions).

[mloskot]

I don't think the fact Boost::polygon is listed in the target_link_libraries changes anything or affects users really.

However, Boost.Geometry is free to manually modify the generated CMakeLists.txt and add its own CMake options to enable/disable optional dependencies.

One of the best examples of Boost libraries which can be used as a standalone library is Boost.JSON which uses hand-crafted CMakeLists.txt.

[barendgehrels]

Apparently, it disturbs some users (the reason why this discussion is started).
But we should not remove optional adaptations, they are just there to show that our library can cooperate, which was and is the intention.
Therefore, and because IMO it really makes no sense to let our library depend on unreal dependencies, I'm in favor of a hand-crafted CMakeLists.txt

[nealkruis]

My intention was not to question how CMakeLists.txt is generated (I was pointing to it as a concise list of other Boost header libraries I suspect are required), but rather try to understand if there is any effort underway in making Boost.Geometry more self-contained. In my experience, it is sometimes hard to convince others to adopt Boost.Geometry because it tends to pull a sizable number of other Boost headers with it.

I have attempted to pare down the requirements for some projects, but my manual approach is not as thorough as I'd like. It's also a process I have to repeat every time I want to update to a newer version of the library. Maybe there are utilities these days that can help identify and remove unused headers? If so, I haven't been able to find any.

So, what I'm really after is finding the minimal subset of Boost needed just for my specific use of the Geometry library. My ideal would be everything in a single repository that I can submodule and update easily when a new version is released.

[mloskot]

rather try to understand if there is any effort underway in making Boost.Geometry more self-contained

The 'self-contained' expectation needs to be clarified.

There are a concepts of building/using Boost.X as

1. Part of Boost super-project
2. A 'client' of Boost e.g. installed system-wide
3. A completely self-contained and standalone library (Asio does that?)

Currently, we do 1.
Potentially, we can do 2. and quite easily.
I'm not too positive we can ever do 3. without a huge effort.

Maybe there are utilities these days that can help identify and remove unused headers?

There is an official tool precisely for that: https://www.boost.org/tools/bcp/

There is another official tool which helps investigate inter-Boost dependencies: https://github.com/boostorg/boostdep
a part of which is depinst.py script which can 'install' sources for minimum set of Boost libraries required by given Boost library

python3 tools/boostdep/depinst/depinst.py geometry

The depinst.py is heavily used by CI jobs across all Boost libraries.