Re: [boost] [type_traits] Rewrite and dependency free version

Subject: Re: [boost] [type_traits] Rewrite and dependency free version
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-02-02 12:52:40

Stephen Kelly-2 wrote
> Peter Dimov wrote:
>>> The reason Stephen talks about splitting serialization is that adding
>>> serialization support needs only a few includes, independent of the rest
>>> of the library.
>> 
>> And in fact if you look through
>> 
>> http://www.pdimov.com/tmp/report-develop-c3bb6eb/serialization.html#reverse-dependencies
>> 
>> you'll see that many, if not most, of the serialization dependencies are
>> like that.
> 
> Yes, but Robert will not discuss splitting it. 
> 
> There's no point even trying to come up with a solution until that
> changes, 
> but it can be pointed to as a problem for anyone willing to listen :).
> 
> That's what I've been trying to point out for months.

I think that there's a lot more too it than "splitting serialization".

a) It's not at all clear what "splitting serialization" means.  Making a two
new DLLS for xml_archives in the same module? That wouldn't change the
dependency graph which is driving this request.  Making a boost level module
just for the XML archives (which use spirit which is what creates the
tendencies which are of concern there? or what?  Either of these is a
serious undertaking - in large part to support auto-linking and who knows
what other surprises.  Probably the bjam test suite would also have to be
re-organized.  And I don't know what all else.  A huge amount of work with
no gain in functionality.

b) One possibility would be re-implement xml_archives not in terms of
spirit.  This would of course be counter productive.

The main problem is the concept of "dependency" as revealed in our charts is
misleading.  When we say one module is dependent upon another what to we
mean?  If the tests use Boost.Test - is the module dependent on boost test? 
well, that would depend on whether or not one plans on running the tests. 
Is serialization dependent on spirit? that would depend on whether one is
going to use xml archives or not.  I don't know how our dependency charting
tool define dependency.  Any discussion of dependency has to start with the
users particular application.  If my app only uses a portion of the library,
only that portion needs to be there (header only library) or be build (other
libraries).  We're already seeing the difficulty of trying to refactor on
the basis of a definition of "dependency" which is not really defined. 
We're chasing our tails.

Step back

a) A useful tool would look like:
tool < list of user application(s), test suites, etc.  > list of headers
and/or library  *.cpp files required.

b) the above could be used to select modules.  For example, if a user of
date-time doesn't use serialization header from date-time - then his app
isn't dependent upon serialization so the he doesn't need to install it. 
The current module graph would show that he does.

c) The above would lead to the conclusion that we need the concept of a
"partial library installation" which of course opens up all kinds of issues. 
However, I can say that what I've done in several cases is to install the
*.cpp files directly into the target apps rather than linking to the
pre-built library.  In other words I've actually used this model to good
effect.

I'm not prepared right now to advocate any radical change in how we do
things - but i just want to make it clear that the current approach to
"minimize dependencies" is too simplistic to be helpful and in fact is
harmful. This topic needs more exploration.

Robert Ramey

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