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-v... Sent from the Boost - Dev mailing list archive at Nabble.com.