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-03 17:26:50

Stephen Kelly-2 wrote
> What way would boost headers be grouped together to make use of that?
> 
>> As far as I can tell, my proposal for "bridging headers" is the only
>> credible specific one suggested so far.  
> 
> Erm, no. You pre-rejected any proposal based on splitting anything
> sensible 
> out of the serialization repo. 

The only thing I recall along this lines was something about "splitting out"
xml?_archives.  It didn't include enough details for me to consider it
credible.

> As the maintainer, you're the only one who  gets to decide.

In boost we more or less have the principle that he who does the work
get's to decide how to do it.  If the rest of us don't like it, it fails to
pass review.  Of course we can change the maintainer - but I don't see
anyone lining up for this job.

> Yay Boost!

agreed

> There's no reason to discuss anything which is pre-rejected.

There's no reason to discuss anything that isn't really a proposal but
rather
a vague idea.

> Does your proposal break the cycle which serialization participates in?

I've looked at the reports and I'm not aware of any cycles.  Feel free to
point out
any of these.  I would be curious about this.

> If it doesn't, then my comment on your proposal is: choose a solution
> which 
> solves the cycle. If it does, please point that out.

In my views cycles aren't an issue.  The shouldn't exist and if they do they 
should be fixed.  I'm wondering if we're thinking the same thing when we use
the word "cycle".

What my proposal seeks to address is the following:

a) someone decides he want's to include the date_time library so he includes
the
header date_time.hpp.  (personally I don't like to include "convenience
headers"
but people in fact do that).

b) this in turn includes date_time/serialization.hpp

c) which in turn includes archive/basic_iarchive and a bunch of other stuff.

d) now when he builds, he finds that he has to download/install the whole 
serialization library even though it's not calling functions in it.

e) so he looks at that dependency report and finds out he has to
download/install 14
other modules. He decides it's too much hassle so he just writes it himself.

Under my proposal date_time/serialization.hpp doesn't include
archive/basic_iarchive.hpp. 
It just has forward declarations class boost::archive::basic_Iarchive;  Now
when 
his application is built, he doesn't have to download/install 14 other
libraries. 
His app will build and run just fine.  Of course if he actually uses
anything from the
serialization library, he'll have to download the "archive" part of it.  But
for now he's
happy.

He could currently avoid all this problem by just not including
data_time/serialization.hpp
unless he actually needs it.  His application isn't dependent upon it.  But
the current
dependency reports don't actually tell him that because they look at the
headers in the
module not in the app.  This is why we need the dependency tools to generate
dependencies
for any group of source files.

(*)But since we're boost, we want to protect library users from themselves
and permit the
usage of convenience headers.  So we implement my scheme.  There's still a
problem.
date_time/serialization.hpp refers to the serialization part of the library
which is header
only.  So that would have to be installed.  This one might be called
"splitting" the library
(though it's actually al ready split - our tools don't recognize this). 
This would require
some thinking - Vicente posted an idea about this.

Another question arises - what do we need the "bridge" module for if each
other module
can declare forward headers.  Answer we don't - except that it's help for
maintenance
to centralize these in one place.  In also include in the serialization
library (archive part)
build to guarantee that they are correct and we're all using the same ones.

So that's what it comes down to:
a) addressing the (*) above
b) thinking more careful what it means for a module(vs an application) to be
dependent and
enhancing the tools to reveal the information that is needed to address the
problem.

Robert Ramey

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