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

Subject: Re: [boost] [modularization] What do we do with "glue" headers?
From: Andrew Hundt (athundt_at_[hidden])
Date: 2013-10-19 16:56:44

On Sat, Oct 19, 2013 at 1:19 PM, Bjørn Roald <bjorn_at_[hidden]> wrote:

> On 10/19/2013 06:59 PM, Daniel James wrote:
>
>> On 19 October 2013 17:40, Andrey Semashev <andrey.semashev_at_[hidden]>
>> 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