Re: [boost] [modularization] What do we do with "glue" headers?

On Sat, Oct 19, 2013 at 1:19 PM, Bjørn Roald wrote:

On 10/19/2013 06:59 PM, Daniel James wrote:

...

On 19 October 2013 17:40, Andrey Semashev wrote:

...

On Saturday 19 October 2013 18:23:54 Mathias Gaunard wrote:

...

On 19/10/13 12:22, John Maddock wrote:

...

A good example would be the serialization lib: a simple dependency tracker would show this up as a dependency to a large part of Boost, but in fact that's not true: in the vast majority of those cases there is no such dependency unless you actually want to use both libraries together and do so by including the "glue" header.

So where does the glue header belong?

In a submodule of the library that depends on both the rest of the library and serialization.

I don't see any need for optional dependencies here.

IMHO, having glue headers in separate repositories is very inconvenient.

We could set it up so that a single repo could contain multiple submodules (i.e. a module for dependency checking is not the same thing as a git submodule).

agree,

I am not sure I like using the term submodule though, it sort of imply it is part of something, and thus that something have the properties of the part, hence we do not get rid of the dependency.

Why not just call them separate components, or modules or something else. They just happen to live in the repository of the library they can add features to if they are used.

-- Bjørn

I've been dealing with this issue very frequently in the last couple years and I've tried a number of the layouts people suggested. Sadly nothing leaves a complete feeling of satisfaction but some are definitely better than others. The one that seems to work best is creating an optional component in a separate header of the same repository. The optional component, rather than the full module or repository comes with a required dependency. For instance, I used an extensions folder in a library with a subfolder for each of the components that add functionality but require additional dependencies. When I tried separate repositories for the core of a single library and every component it quickly became unwieldy. One reason is that it isn't as simple to move files between repositories and reviewing the history of changes in files and structure becomes significantly less convenient. Most of my experience in this sort of structure is with mercurial w/ subrepositories + CMake, so Git may be better at some things. Another problem I'm still hoping to find a good solution for is what to do with headers with no dependencies that either define a constant or provide some other basic definition that makes sense to use in many libraries. I know there are a couple of headers that are exactly like this in Boost that are widely included. Does anyone have insight into good ways to handle these issues as well? There are other cases where some useful components could be split off from within libraries. For instance, many libraries could make use of boost::math::constants in cases where it doesn't make as much sense to have all of the statistical functions come along as another dependency. There are also a number of headers in other libraries that set up a design of some sort that could be useful outside the scope of the individual libraries as well, such as the tag dispatching utilities in boost::geometry. Obviously there are limits to what makes sense to split up, but perhaps there are improved ways we can think about and make these divisions. For example, could there be a smart way to split off some of the general low level concepts and utility objects/functions so they can be documented and used more widely themselves? Cheers! Andrew Hundt