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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk