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

Subject: Re: [boost] [modularization] What do we do with "glue" headers?
From: John Maddock (john_at_[hidden])
Date: 2013-10-20 07:13:55

>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 a number of libraries which use the "core" of boost.math but don't 
need the whole thing - one that causes cyclic dependencies because of this 
is lexical_cast which is both used by Boost.Math (including the constants 
code unfortunately), and also uses a few core Math lib functions.  One way 
to avoid that would be to split off a "Math.Core" lib which contained only a 
few common headers (no tests or docs etc).  Trouble is constants can't be 
part of the core as it would bring back those cyclic dependencies to 
lexical_cast.  They could be their own module I guess, but I'd really like 
to avoid too many splits.

With regard to glue headers - the conclusion I've come to is that we need to 
manually break (by which I mean ignore) some dependencies.

Consider, if lib B has a glue header for interoperability with lib A, then 
there's not any need to automatically track dependencies to A.  After all 
the whole point of the glue header is to use the two libraries together, so 
it's not like the user doesn't know that they need both modules.

To consider another cyclic dependency: the Math and Multiprecision libs.  In 
fact a human observer looking at the code would conclude the dependency 
graph goes in one direction - from Multiprecision to Math (again a small 
part of it).  But there is one Math lib header which *may* under some 
circumstances (user sets a particular macro) include some multiprecision 
headers.  Further that header only exists to assist in the generation of new 
numeric constants - whether by the user or by the Math lib's maintainers. 
So it's usage will be very infrequent, and since the user has to explicitly 
tell it to use Boost.Multiprecision it's not like they don't know that it's 
needed.

I guess we could use macro's to obfuscate the #includes so there's no 
dependency tracking in these cases, but it seems a stupid thing to do 
(obfuscating the code, and possibly breaking build tool support) just to 
keep the modularization folks happy.  So I think I'd like the folks pushing 
for modularization to provide a way for us to annotate headers with a "don't 
track here" direction.

Thoughts?

John.