A few more critical dependencies
At present, we have three dependencies that we can easily cut and doing so will be very beneficial: 1. type_traits now depends on utility only because utility: <boost/utility/declval.hpp> from <boost/type_traits/common_type.hpp> from <boost/type_traits/detail/common_type_imp.hpp> from <boost/type_traits/is_copy_constructible.hpp> from <boost/type_traits/is_nothrow_move_assignable.hpp> from <boost/type_traits/is_nothrow_move_constructible.hpp> Since declval.hpp itself depends on type_traits (add_rvalue_reference), it can't go to core and the most logical place for it is type_traits itself. 2. utility depends on iterator because iterator: <boost/iterator.hpp> from <boost/operators.hpp> <boost/iterator/iterator_facade.hpp> from <boost/generator_iterator.hpp> boost/iterator.hpp can be moved to core in all its former glory (and probably replaced by a one-liner, using std::iterator.) generator_iterator.hpp perhaps needs to be moved to iterator. 3. mpl depends on detail because detail: <boost/detail/endian.hpp> from <boost/mpl/string.hpp> <boost/detail/lightweight_test.hpp> from <boost/mpl/aux_/test.hpp> That last one is just because lightweight_test.hpp hasn't been removed from Detail yet; let me know if I should do that. boost/detail/endian.hpp is just a forwarding header that includes <boost/predef/detail/endian_compat.h>. We should move it to Predef. Comments? Objections?
On Mon, Jun 2, 2014 at 4:04 PM, Peter Dimov <lists@pdimov.com> wrote:
Although I would gladly accept a move of boost/detail/endian.hpp to Predef (since I'm the sole author at this point). A much nicer solution would be to change boost/mpl/string.hpp to use the non-detail endian macros of Predef. As ti gets us closer to removing detail/endian.hpp entirely. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera wrote:
Also possible. Moving the header will however also "fix" (as in, remove their dependency on Detail) its other uses: Inclusion report for <boost/detail/endian.hpp> (in module detail): from math: <boost/math/special_functions/detail/fp_traits.hpp> from mpl: <boost/mpl/string.hpp> from multiprecision: <boost/multiprecision/cpp_int.hpp> from serialization: <boost/archive/impl/basic_binary_iarchive.ipp> from spirit: <boost/spirit/home/support/detail/endian/endian.hpp> <boost/spirit/home/support/detail/math/detail/fp_traits.hpp> We could also fix them all "properly", it's just more work and less immediate.
On Tue, Jun 3, 2014 at 2:50 AM, John Maddock <boost.regex@virgin.net> wrote:
+1, assuming all the necessary predef code is in release?
I'm working on the last changes to the Predef docs. And will merge Predef to it's master branch soon. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On Wed, Jun 4, 2014 at 8:25 PM, Peter Dimov <lists@pdimov.com> wrote:
OK.. Could someone send me the pull request? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On Thu, Jun 5, 2014 at 9:55 AM, Peter Dimov <lists@pdimov.com> wrote:
I can't merge from develop to master now :-( -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera wrote:
I can't merge from develop to master now :-(
Why not? I can: C:\Projects\boost-git\boost\libs\predef>git status # On branch master nothing to commit, working directory clean C:\Projects\boost-git\boost\libs\predef>git pull Already up-to-date. C:\Projects\boost-git\boost\libs\predef>git merge develop Auto-merging build.jam Merge made by the 'recursive' strategy. jamroot.jam => build.jam | 3 +-- test/.gitignore | 1 + 2 files changed, 2 insertions(+), 2 deletions(-) rename jamroot.jam => build.jam (81%) C:\Projects\boost-git\boost\libs\predef>git status # On branch master # Your branch is ahead of 'origin/master' by 18 commits. # (use "git push" to publish your local commits) # nothing to commit, working directory clean
OK, I tried again and it worked. No idea what happened on my first try. Git mysteries :-\ On Thu, Jun 5, 2014 at 10:11 AM, Peter Dimov <lists@pdimov.com> wrote:
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
OK, it's the automatic merge on github I can no longer do. Two things: 1. In the future please do not fast-forward history on master branches. It messes up the natural flow of the git history. 2. Could you do me the favor of merging on the command line? I don't have access to the CLI at the moment and really want to get the master test results showing up again. On Thu, Jun 5, 2014 at 10:19 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera wrote:
OK, it's the automatic merge on github I can no longer do. Two things:
It was the latest commit, "Reverting (c) to human author", that created the merge conflict.
1. In the future please do not fast-forward history on master branches. It messes up the natural flow of the git history.
I didn't fast-forward history, if by that you mean "git merge develop" - I moved the file via git log / git am in both branches per https://svn.boost.org/trac/boost/wiki/NewLibByRefactor Most of the history of this file is from the SVN and the transition doesn't preserve any merge points, so the two branches appear completely separate, even though the commits turn out to be actually identical in this case.
2. Could you do me the favor of merging on the command line?
Done. I had to cherry-pick the latest develop commit first though, to avoid the conflict. C:\Projects\boost-git\boost\libs\predef>git cherry-pick develop [master bcdaa18] Reverting (c) to human author. Author: Rene Rivera <grafikrobot@gmail.com> 1 file changed, 1 insertion(+), 1 deletion(-) C:\Projects\boost-git\boost\libs\predef>git status # On branch master # Your branch is ahead of 'origin/master' by 1 commit. # (use "git push" to publish your local commits) # nothing to commit, working directory clean C:\Projects\boost-git\boost\libs\predef>git merge --no-ff develop Auto-merging build.jam Merge made by the 'recursive' strategy. jamroot.jam => build.jam | 3 +-- test/.gitignore | 1 + 2 files changed, 2 insertions(+), 2 deletions(-) rename jamroot.jam => build.jam (81%) C:\Projects\boost-git\boost\libs\predef>git status # On branch master # Your branch is ahead of 'origin/master' by 20 commits. # (use "git push" to publish your local commits) # nothing to commit, working directory clean C:\Projects\boost-git\boost\libs\predef>git diff master..develop C:\Projects\boost-git\boost\libs\predef>git push Counting objects: 5, done. Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 481 bytes | 0 bytes/s, done. Total 3 (delta 1), reused 0 (delta 0) To https://github.com/boostorg/predef.git 4dd9dc7..3902dd7 master -> master
On 5 June 2014 17:01, Peter Dimov <lists@pdimov.com> wrote:
That's because 'git log' includes the commits from both branches when they're merged. I don't know why you think you need to transfer all the history, but if you really must, put it in a branch from the merge base of origin and develop (i.e. git checkout $(git merge-base origin/master origin/develop) -b whatever), and then do a non fast forward merge into both branches - so that it's obvious that it's a separate line of development, and you don't need to merge existing changes in develop in order to do that. But I wouldn't transfer the history, it just creates a load of noise that gets in the way. And it isn't at all clear what happened. If someone wants to see the old history, it's easy enough to check the original repo.
Daniel James wrote:
But I wouldn't transfer the history, it just creates a load of noise that gets in the way. And it isn't at all clear what happened.
Well that certainly would be much easier. In principle, you could do "git log --follow -- file" and see the history. That's basically the only thing that moving the history gives us. And I suspect that it might be convenient for people who like to right-click on things and choose "Log" from the menu. It does create a lot of noise in "git log" though.
If someone wants to see the old history, it's easy enough to check the original repo.
Not if you didn't know what the original repo was. :-)
On 6 June 2014 00:42, Daniel James <dnljms@gmail.com> wrote:
I think a better way to do this is to create a copy of the repo, use 'git filter-branch' to reduce the history to the files you want, then fetch the appropriate branches into the destination, and merge the branch into your tree. There's an example of using 'git filter-branch' at http://stackoverflow.com/a/6006679/2434.
On 2 June 2014 22:04, Peter Dimov <lists@pdimov.com> wrote:
boost/iterator.hpp can be moved to core in all its former glory (and probably replaced by a one-liner, using std::iterator.)
Or other libraries could be changed to use std::iterator. Is it worth adding an obsolete header to core?
Daniel James wrote:
Moving it is the safer choice; if it turns out that we do need to workaround some uses of std::iterator after all, the changes will be isolated to a single place. But either way is fine with me. Here's the report on boost/iterator.hpp, if we choose the second option: Inclusion report for <boost/iterator.hpp> (in module iterator): from circular_buffer: <boost/circular_buffer/details.hpp> from concept_check: <boost/concept_archetype.hpp> <boost/concept_check.hpp> from filesystem: <boost/filesystem/operations.hpp> from geometry: <boost/geometry/geometries/adapted/boost_polygon/hole_iterator.hpp> <boost/geometry/iterators/base.hpp> <boost/geometry/iterators/closing_iterator.hpp> <boost/geometry/iterators/ever_circling_iterator.hpp> <boost/geometry/views/detail/points_view.hpp> from graph: <boost/graph/adjacency_matrix.hpp> <boost/graph/stanford_graph.hpp> <boost/graph/vector_as_graph.hpp> from multi_array: <boost/multi_array/algorithm.hpp> from spirit: <boost/spirit/home/classic/iterator/multi_pass.hpp> <boost/spirit/home/support/iterators/detail/multi_pass.hpp> from unordered: <boost/unordered/detail/buckets.hpp> from utility: <boost/operators.hpp>
participants (6)
-
Daniel James -
John Maddock -
Julian Gonggrijp -
Peter Dimov -
Rene Rivera -
Vicente J. Botet Escriba