I haven't run one of these in a while, so here it is. http://pdimov.com/tmp/report-develop-6db78a0a6/module-overview.html http://pdimov.com/tmp/report-develop-6db78a0a6/module-levels.html http://pdimov.com/tmp/report-develop-6db78a0a6/module-weights.html We have one "supermodule" at level 5 and another at level 13.
http://pdimov.com/tmp/report-develop-6db78a0a6/module-levels.html
One obvious low-hanging fruit here is moving
On 07/17/17 16:29, Peter Dimov via Boost wrote:
http://pdimov.com/tmp/report-develop-6db78a0a6/module-levels.html
One obvious low-hanging fruit here is moving
from utility to iterator, breaking the utility -> iterator edge; I think this was discussed recently?
I don't think it was (or may be I missed it). Strictly speaking, boost::next/prior is not tied to iterators; it is compatible with any type that has the necessary operators (e.g. integers). Although the use case with iterators is probably the most frequent.
Andrey Semashev wrote:
Strictly speaking, boost::next/prior is not tied to iterators; it is compatible with any type that has the necessary operators (e.g. integers).
Is it possible to deprecate the use of boost::next/prior for non-iterator types? For non-iterator types, boost::next requires op+ or op+= (and similarly boost::prior requires op- or op-=). I think we can just use op+, unless the type has op+= but not op+. Regards, Michel
On 07/18/17 03:44, Michel Morin via Boost wrote:
Andrey Semashev wrote:
Strictly speaking, boost::next/prior is not tied to iterators; it is compatible with any type that has the necessary operators (e.g. integers).
Is it possible to deprecate the use of boost::next/prior for non-iterator types?
It is possible, but I'm not sure why we would do that. What is the problem that we're trying to solve?
Andrey Semashev wrote:
On 07/18/17 03:44, Michel Morin via Boost wrote:
Is it possible to deprecate the use of boost::next/prior for non-iterator types?
It is possible, but I'm not sure why we would do that. What is the problem that we're trying to solve?
If Utility's dependency on Iterator is a problem, the deprecation can help to move boost::next/prior to Iterator. But the dependency is not a problem for me... Regards, Michel
Michel Morin wrote:
Andrey Semashev wrote:
On 07/18/17 03:44, Michel Morin via Boost wrote:
Is it possible to deprecate the use of boost::next/prior for non-iterator types?
It is possible, but I'm not sure why we would do that. What is the problem that we're trying to solve?
If Utility's dependency on Iterator is a problem, the deprecation can help to move boost::next/prior to Iterator.
Yes please, let's move next_prior.hpp to Iterator while we're on this topic. This dependency is not the end of the world by any means, but it would still be a small step in the right direction. It's true that next/prior are not limited to iterators, and that's fine, there's no need to deprecate their use for non-iterators.
New and improved reports here: https://pdimov.github.io/boostdep-report/
Yes please, let's move next_prior.hpp to Iterator while we're on this topic. This dependency is not the end of the world by any means, but it would still be a small step in the right direction.
utility -> iterator is the cause of a bunch of modules forming a tight group at level 5: https://pdimov.github.io/boostdep-report/develop/module-levels.html#level:5 which consequently makes all of them have 25 dependencies each: https://pdimov.github.io/boostdep-report/develop/module-weights.html#weight:...
On 07/27/17 14:02, Peter Dimov via Boost wrote:
New and improved reports here:
Looks great! It should really be run routinely along with source code checks so that it is always actual and accessible through the website.
Yes please, let's move next_prior.hpp to Iterator while we're on this topic. This dependency is not the end of the world by any means, but it would still be a small step in the right direction.
utility -> iterator is the cause of a bunch of modules forming a tight group at level 5:
https://pdimov.github.io/boostdep-report/develop/module-levels.html#level:5
I don't quite understand what level means.
which consequently makes all of them have 25 dependencies each:
https://pdimov.github.io/boostdep-report/develop/module-weights.html#weight:...
I don't quite remember how we moved headers between submodules in the past. I think it required someone with commit rights to both submodules? In any case, I don't mind if next_prior.hpp along with its tests and docs is moved to Boost.Iterator, just let me know what I can do. Also, if so requested, I can revert the commit that adds the dependency (with the loss of the optimization it adds).
Andrey Semashev wrote:
https://pdimov.github.io/boostdep-report/develop/module-levels.html#level:5
I don't quite understand what level means.
Level is an artificial measure computed by placing all modules with no dependencies at level 0, those that depend on level 0 on level 1, and so on.
I don't quite remember how we moved headers between submodules in the past. I think it required someone with commit rights to both submodules?
In the past I moved headers along with their history by exporting the commits to a text file and then applying that in the target repo, but I think that's too much trouble for little worth. We could just remove it from utility and commit it to iterator.
In any case, I don't mind if next_prior.hpp along with its tests and docs is moved to Boost.Iterator, just let me know what I can do.
I see you're already on the "utility" team, I can add you to the "iterator" team if Edward doesn't object?
On 07/27/17 15:42, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
https://pdimov.github.io/boostdep-report/develop/module-levels.html#level:5
I don't quite understand what level means.
Level is an artificial measure computed by placing all modules with no dependencies at level 0, those that depend on level 0 on level 1, and so on.
But there are modules within level 5 that depend on other modules in level 5. And also other modules that only depend on level 4 (e.g. exception).
I don't quite remember how we moved headers between submodules in the past. I think it required someone with commit rights to both submodules?
In the past I moved headers along with their history by exporting the commits to a text file and then applying that in the target repo, but I think that's too much trouble for little worth. We could just remove it from utility and commit it to iterator.
I think history is worth retaining.
In any case, I don't mind if next_prior.hpp along with its tests and docs is moved to Boost.Iterator, just let me know what I can do.
I see you're already on the "utility" team, I can add you to the "iterator" team if Edward doesn't object?
I'd be ok with that.
Andrey Semashev wrote:
Level is an artificial measure computed by placing all modules with no dependencies at level 0, those that depend on level 0 on level 1, and so on.
But there are modules within level 5 that depend on other modules in level 5. And also other modules that only depend on level 4 (e.g. exception).
This is what happens when there are circular dependencies. When A depends on B and B depends on A, it's not possible to make both A (level of B)+1 and B (level of A)+1, so they are placed at the same level.
On 7/27/2017 8:42 AM, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
https://pdimov.github.io/boostdep-report/develop/module-levels.html#level:5
I don't quite understand what level means.
Level is an artificial measure computed by placing all modules with no dependencies at level 0, those that depend on level 0 on level 1, and so on.
I don't quite remember how we moved headers between submodules in the past. I think it required someone with commit rights to both submodules?
In the past I moved headers along with their history by exporting the commits to a text file and then applying that in the target repo, but I think that's too much trouble for little worth. We could just remove it from utility and commit it to iterator.
In any case, I don't mind if next_prior.hpp along with its tests and docs is moved to Boost.Iterator, just let me know what I can do.
I see you're already on the "utility" team, I can add you to the "iterator" team if Edward doesn't object?
I do not object.
Peter Dimov wrote:
In the past I moved headers along with their history by exporting the commits to a text file and then applying that in the target repo,
After the move, the original file is split into the two files:
one contains the actual code and the other is for the backward compatibility.
Did you transfer the history into only one of the two files?
Or can git allowed to transfer the history to both of the two split files?
This is an example of moving next_prior.hpp:
===============
Before the move
===============
[Boost.Iterator]
Does not contain anything related to next_prior.hpp.
[Boost.Utility]
Contains the following:
- include/boost/utility/next_prior.hpp
==============
After the move
==============
[Boost.Iterator module]
Contains the following:
- include/boost/iterator/next_prior.hpp
* Contains the actual code for `next` and `prior`.
- include/boost/utility/next_prior.hpp
* Just includes
Michel Morin wrote:
Peter Dimov wrote:
In the past I moved headers along with their history by exporting the commits to a text file and then applying that in the target repo,
After the move, the original file is split into the two files: one contains the actual code and the other is for the backward compatibility. Did you transfer the history into only one of the two files?
I moved the file as-is from the first repo to the other, as described here: https://svn.boost.org/trac10/wiki/NewLibByRefactor Then, assuming the result is include/boost/utility/next_prior.hpp in repo iterator, I would rename it with `git mv` to include/boost/iterator/next_prior.hpp. This ought to retain history. I would then create the new forwarding file with the old name in a separate commit.
Peter Dimov wrote:
Michel Morin wrote:
After the move, the original file is split into the two files: one contains the actual code and the other is for the backward compatibility. Did you transfer the history into only one of the two files?
I moved the file as-is from the first repo to the other, as described here:
Thanks for the link, I didn't know that such a page exists.
Then, assuming the result is include/boost/utility/next_prior.hpp in repo iterator, I would rename it with `git mv` to include/boost/iterator/next_prior.hpp. This ought to retain history. I would then create the new forwarding file with the old name in a separate commit.
So `include/boost/iterator/next_prior.hpp ` retains history and `include/boost/utility/next_prior.hpp ` is a new file. That makes sense, thanks again. Regards, Michel
On 07/27/17 22:06, Peter Dimov via Boost wrote:
Michel Morin wrote:
In the past I moved headers along with their history by exporting
Peter Dimov wrote: the > commits to a text file and then applying that in the target repo,
After the move, the original file is split into the two files: one contains the actual code and the other is for the backward compatibility. Did you transfer the history into only one of the two files?
I moved the file as-is from the first repo to the other, as described here:
https://svn.boost.org/trac10/wiki/NewLibByRefactor
Then, assuming the result is include/boost/utility/next_prior.hpp in repo iterator, I would rename it with `git mv` to include/boost/iterator/next_prior.hpp. This ought to retain history. I would then create the new forwarding file with the old name in a separate commit.
There is just boost/next_prior.hpp, so no need to move it, unless we also want to clean up the top-level include directory. I will move it from Utility to Iterator after 1.65 is out. I don't think this is urgent and I'd rather not cause an unnecessary disruption now. Besides, the file is different in develop and master because develop depends on a new feature in Config that has not been merged yet.
On 28/07/2017 02:53, Michel Morin wrote:
============== After the move ============== [Boost.Iterator module] Contains the following: - include/boost/iterator/next_prior.hpp * Contains the actual code for `next` and `prior`. - include/boost/utility/next_prior.hpp * Just includes
. [Boost.Utility module] Does not contain anything related to next_prior.hpp.
While this arrangement sort of makes sense for the purposes of cleaning a dependency graph, doesn't this just proliferate the problem of header files in the "wrong" directory for its library? ie. shouldn't the forwarding header file still be owned by Boost.Utility? Admittedly that doesn't fix the dependency graph, unless you make it ignore that forwarding header ... which is probably only ok if you can also guarantee that no in-Boost code actually *uses* that header, otherwise it's still a real dependency. But there's probably a few other compatibility/forwarding header files that might fit that bill and should perhaps be similarly excluded, which might mean the dependencies aren't quite as bad as they currently appear. I guess it's a question of which problem is worse.
Gavin Lambert wrote:
While this arrangement sort of makes sense for the purposes of cleaning a dependency graph, doesn't this just proliferate the problem of header files in the "wrong" directory for its library?
At some point we should probably add deprecation warnings to the wrongly-owned headers, to enable their removal further down the line.
Peter Dimov wrote:
Gavin Lambert wrote:
While this arrangement sort of makes sense for the purposes of cleaning a dependency graph, doesn't this just proliferate the problem of header files in the "wrong" directory for its library?
At some point we should probably add deprecation warnings to the wrongly-owned headers, to enable their removal further down the line.
We can add the following to the forwarding headers _now_
so as not to forget to deprecate them ;)
#include
Peter Dimov wrote:
One obvious low-hanging fruit here is moving
from utility to iterator, breaking the utility -> iterator edge; I think this was discussed recently?
I posted a related thread last month during the discussion on IteratorTraversalCategory-aware boost::advance (at that time, I didn't know that boost::next/prior is not only for iterators), but I got no response: [boost] [iterator][utility] Move utility/next_prior.hpp to Iterator module? https://lists.boost.org/Archives/boost/2017/06/236656.php Regards, Michel
On 7/17/2017 6:11 PM, Michel Morin via Boost wrote:
Peter Dimov wrote:
One obvious low-hanging fruit here is moving
from utility to iterator, breaking the utility -> iterator edge; I think this was discussed recently? I posted a related thread last month during the discussion on IteratorTraversalCategory-aware boost::advance (at that time, I didn't know that boost::next/prior is not only for iterators), but I got no response:
[boost] [iterator][utility] Move utility/next_prior.hpp to Iterator module? https://lists.boost.org/Archives/boost/2017/06/236656.php
The change pushed by Andrey was to have iterator not use boost::prior rather than to move boost/next_prior.hpp to iterator.
Regards, Michel
Edward Diener wrote:
The change pushed by Andrey was to have iterator not use boost::prior rather than to move boost/next_prior.hpp to iterator.
Right, that change is to cut the cyclic dependency between boost/next_prior.hpp and boost/iterator/reverse_iterator.hpp. Andrey also pushed the change where boost/next_prior.hpp started to use boost/iterator/advance.hpp. Regards, Michel
On 7/17/17 5:04 AM, Peter Dimov via Boost wrote:
I haven't run one of these in a while, so here it is.
http://pdimov.com/tmp/report-develop-6db78a0a6/module-overview.html http://pdimov.com/tmp/report-develop-6db78a0a6/module-levels.html http://pdimov.com/tmp/report-develop-6db78a0a6/module-weights.html
We have one "supermodule" at level 5 and another at level 13.
I like these reports and find them interesting. But one thing would make them much more useful to me. Consider the following scenario: I have a small app which uses the date_time library. I would like to know what boost modules I need to include. I look on your charts, and see that date-time has a primary dependency on the serialization library. This suggests that I need to include the serialization library in my small app to make it work - which is actually untrue. Now what useful information has your report given me? The problem of is that my small app includes only those headers from date-time that it actually needs. So a useful dependency report would only follow those headers. So..... Could I ask for a feature enhancement for these tools (assuming they don't already have it). Could I list a set of source files which would constitute the "root" of the the dependency search. Then I could make my small app run your tools with tool "small_app.cpp" Get a list of boost submodules that I need to package/deliver with my small app. Seems like it would not be too difficult to add this facility and it would be pretty useful. I would like to see it added tot he boost/tools directory as a complement to bcp. Robert Ramey
Robert Ramey wrote:
I like these reports and find them interesting. But one thing would make them much more useful to me. Consider the following scenario:
I have a small app which uses the date_time library. I would like to know what boost modules I need to include. I look on your charts, and see that date-time has a primary dependency on the serialization library. This suggests that I need to include the serialization library in my small app to make it work - which is actually untrue. Now what useful information has your report given me?
The problem of is that my small app includes only those headers from date-time that it actually needs. So a useful dependency report would only follow those headers. So.....
Could I ask for a feature enhancement for these tools (assuming they don't already have it). Could I list a set of source files which would constitute the "root" of the the dependency search.
I've added a --subset-for option to boostdep; you can't give it a list of sources, but you give it a directory containing them, so dist\bin\boostdep --subset-for d:\my_projects\my_app will give you the Boost subset included by the files in d:\my_projects\my_app.
Le 17.07.17 à 14:04, Peter Dimov via Boost a écrit :
I haven't run one of these in a while, so here it is.
http://pdimov.com/tmp/report-develop-6db78a0a6/module-overview.html http://pdimov.com/tmp/report-develop-6db78a0a6/module-levels.html http://pdimov.com/tmp/report-develop-6db78a0a6/module-weights.html
We have one "supermodule" at level 5 and another at level 13.
Hi, For some libraries that are using boost.test, it seems that boost.test is included in the weight. But this is in fact not totally true: as it is shown, it is a "developer" weight that wants to run the tests and compile the doc. Would it be somehow possible to account only for the source code that generates the libraries, as seen by users? Thanks, Raffi
Hi,
For some libraries that are using boost.test, it seems that boost.test is included in the weight. But this is in fact not totally true: as it is shown, it is a "developer" weight that wants to run the tests and compile
Raffi Enficiaud wrote: the doc. The dependencies in the report are computed based on the headers in `include`. If one of them includes a Boost.Test header, Test is considered a dependency. The usual practice is to move such private headers to the `test` subdirectory.
Would it be somehow possible to account only for the source code that generates the libraries, as seen by users?
This would imply that header-only libraries have no dependencies, which is absurd.
Le 30.07.17 à 10:51, Peter Dimov via Boost a écrit :
Raffi Enficiaud wrote:
Hi,
For some libraries that are using boost.test, it seems that boost.test is included in the weight. But this is in fact not totally true: as it is shown, it is a "developer" weight that wants to run the tests and compile the doc.
The dependencies in the report are computed based on the headers in `include`. If one of them includes a Boost.Test header, Test is considered a dependency.
The usual practice is to move such private headers to the `test` subdirectory.
That is weird though that eg. boost.graph depends on boost.test. After
your reply, it is indeed in
Would it be somehow possible to account only for the source code that generates the libraries, as seen by users?
This would imply that header-only libraries have no dependencies, which is absurd.
You got me wrong here. Best, Raffi
Le 30.07.17 à 14:21, Raffi Enficiaud via Boost a écrit :
Le 30.07.17 à 10:51, Peter Dimov via Boost a écrit :
Raffi Enficiaud wrote:
Hi,
For some libraries that are using boost.test, it seems that boost.test is included in the weight. But this is in fact not totally true: as it is shown, it is a "developer" weight that wants to run the tests and compile the doc.
The dependencies in the report are computed based on the headers in `include`. If one of them includes a Boost.Test header, Test is considered a dependency.
The usual practice is to move such private headers to the `test` subdirectory.
That is weird though that eg. boost.graph depends on boost.test. After your reply, it is indeed in
which should then be indeed moved somewhere else.
However, still bimap refers to test as a "secondary dependency". What does that mean? Thanks, Raffi
Would it be somehow possible to account only for the source code that generates the libraries, as seen by users?
This would imply that header-only libraries have no dependencies, which is absurd.
You got me wrong here.
Best, Raffi
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Raffi Enficiaud wrote:
However, still bimap refers to test as a "secondary dependency". What does that mean?
bimap depends on property_map: https://pdimov.github.io/boostdep-report/develop/bimap.html#property_map which depends on mpi: https://pdimov.github.io/boostdep-report/develop/property_map.html#mpi which depends on graph: https://pdimov.github.io/boostdep-report/develop/mpi.html#graph which depends on test: https://pdimov.github.io/boostdep-report/develop/graph.html#test
Le 30.07.17 à 19:24, Peter Dimov via Boost a écrit :
Raffi Enficiaud wrote:
However, still bimap refers to test as a "secondary dependency". What does that mean?
bimap depends on property_map:
https://pdimov.github.io/boostdep-report/develop/bimap.html#property_map
which depends on mpi:
https://pdimov.github.io/boostdep-report/develop/property_map.html#mpi
which depends on graph:
https://pdimov.github.io/boostdep-report/develop/mpi.html#graph
which depends on test:
https://pdimov.github.io/boostdep-report/develop/graph.html#test
Thanks, but to go back to my question, "secondary dependency" means the union of all sources in the dependency graph, is that correct? Nice tool BTW (although seeing mpi<-property_map and test<-graph is a bit scary I have to say). Raffi
On 7/30/2017 8:21 AM, Raffi Enficiaud via Boost wrote:
Le 30.07.17 à 10:51, Peter Dimov via Boost a écrit :
Raffi Enficiaud wrote:
Hi,
For some libraries that are using boost.test, it seems that boost.test is included in the weight. But this is in fact not totally true: as it is shown, it is a "developer" weight that wants to run the tests and compile the doc.
The dependencies in the report are computed based on the headers in `include`. If one of them includes a Boost.Test header, Test is considered a dependency.
The usual practice is to move such private headers to the `test` subdirectory.
That is weird though that eg. boost.graph depends on boost.test. After your reply, it is indeed in
which should then be indeed moved somewhere else.
I agree with you. The
Would it be somehow possible to account only for the source code that generates the libraries, as seen by users?
This would imply that header-only libraries have no dependencies, which is absurd.
You got me wrong here.
Best, Raffi
On 7/30/2017 8:21 AM, Raffi Enficiaud via Boost wrote:
Le 30.07.17 à 10:51, Peter Dimov via Boost a écrit :
Raffi Enficiaud wrote:
Hi,
For some libraries that are using boost.test, it seems that boost.test is included in the weight. But this is in fact not totally true: as it is shown, it is a "developer" weight that wants to run the tests and compile the doc.
The dependencies in the report are computed based on the headers in `include`. If one of them includes a Boost.Test header, Test is considered a dependency.
The usual practice is to move such private headers to the `test` subdirectory.
That is weird though that eg. boost.graph depends on boost.test. After your reply, it is indeed in
which should then be indeed moved somewhere else.
I created a PR to move graph_test.hpp to the test subdirectory.
Would it be somehow possible to account only for the source code that generates the libraries, as seen by users?
This would imply that header-only libraries have no dependencies, which is absurd.
You got me wrong here.
Best, Raffi
participants (7)
-
Andrey Semashev -
Edward Diener -
Gavin Lambert -
Michel Morin -
Peter Dimov -
Raffi Enficiaud -
Robert Ramey