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
> 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
> 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!
> 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
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
any of these. I would be curious about this.
> If it doesn't, then my comment on your proposal is: choose a solution
> 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
header date_time.hpp. (personally I don't like to include "convenience
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
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
It just has forward declarations class boost::archive::basic_Iarchive; Now
his application is built, he doesn't have to download/install 14 other
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
He could currently avoid all this problem by just not including
unless he actually needs it. His application isn't dependent upon it. But
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
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
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
can declare forward headers. Answer we don't - except that it's help for
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
enhancing the tools to reveal the information that is needed to address the
-- 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.