Boost logo

Boost :

Subject: Re: [boost] [type_traits] Rewrite and dependency free version
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-02-02 18:51:17


The current situation with date-time is the following:

user creates application which doesn't use serialization. Hence he doesn't
include boost/data-time/serialization.hpp. His program compiles, links and
runs. Clearly his program depends on boost/date-tiem but doesn't depend on
boost serialization. I don't think this is a disputable fact. The module
dependency tool may say that anything which depends upon date-time library
is dependent upon serialization - but that is not true. I don't think this
is disputable.

So in my view the module decency tool should take one or more program
sources as arguments and generate a list of modules which need to be
included in order to compile/link and run the all the programs. This would
tell a user exactly what he needs to know.

When I test the date-time library I would include all the test programs as
arguments and get one list of modules. Someone else might be only
interested in one application and get a shorter list of modules. This would
be useful to everyone.

There will and can never exist at tool which gives you the exact list of
required modules with specifying the applications to be built.

So we're going to settle for some approximation. That's OK. it's better
than nothing - but don't think that it's anything other than this. The
current approximation is that of tracking the header inclusions. This
includes more than a given application is likely to use so it's sort of
overkill - this shows up as union of all possible modules which some
application might need to build. It's not incorrect, just recognize that
it's a blunt instrument.

I can hear the cry - so what can we do so one doesn't have to download the
whole of boost? Here's a suggestion which may satisfy those.

Modest Proposal - Bridge module

We create a new module - named "bridge". In this module there is a
directory: boost/bridge/archive.hpp. This contains only forward
declarations:

class basic_iarchive;
class basic_oarchive;

and maybe some other miscellaneous stuff. This includes no headers from
boost/archive.

in date-time/serialization.hpp files in other libraries replace

#include <boost/archive/basic_iarchive.hpp>
with
#include <boost/bridge/archive.hpp>

Same is done in other libraries which implement serialization;

Everything works the same as before. BUT the dependency tools now stop
looking when they get to the bridge header. So our dependency display stops
at date-time. I think this is an accurate reflection of what is desired.

The building of applications which use date-time is exactly the same as it
was before. The requirement to include (or not include) the boost
serialization libraries is the same - that is it depends on which part of
date-time the application actually uses. But there is a small difference -
the application isn't including anything from boost/archive so the
serialization library doesn't show up as dependent in the tools. Only the
headers from boost/serialization are included. They are all header only and
generally not dependent upon a lot of other boost stuff. This might be
satisfactory.

It does leave us with two different definitions of "module" though. since
both boost/serialization and boost/archive are currently in the same
"module". In fact most of the tests actually test things in serialization
against all the "archives". So teasing this out could be a pain. I'm not
even going to think about this now.

I'm guessing that other libraries have some similar issues. This was raised
previously by John Maddock under the heading "bridge libraries" he posed the
question about how to deal with and we didn't really have an answer ...
then.

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/type-traits-Rewrite-and-dependency-free-version-tp4671061p4671945.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk