Fletcher, John P wrote:
These do not look like links to me:
fletcher@fletcher-desktop:~/boost_maintenance/modular-boost/boost$ ls -l int*.hpp -rw-rw-r-- 1 fletcher fletcher 4617 Jan 19 2014 integer_fwd.hpp -rw-rw-r-- 1 fletcher fletcher 11314 Jan 19 2014 integer.hpp -rw-rw-r-- 1 fletcher fletcher 8317 Jan 20 2014 integer_traits.hpp
Nope, they look like straight copies.
The workaround is usually to delete boost/ and recreate it with b2 headers, but this shouldn't be necessary, at least in theory.
I could try this, but what does it do with the files in /boost which are not links? Is there a file somewhere which tells it which things to copy? I have run ./b2 headers on my present setup and that runs clean.
This is a Boost.Build issue and I don't understand it very well. I have a rough idea what happens though. Boost.Build checks if it can use symlinks, which is this part of its output: Performing configuration checks - symlinks supported : no (cached) - junctions supported : yes (cached) - hardlinks supported : yes (cached) I'm on Windows (without symlink rights), so it detects that it can't symlink. For you, the output would probably be Performing configuration checks - symlinks supported : yes (cached) - hardlinks supported : yes (cached) Now, it goes to check whether to copy/hardlink/symlink boost/integer_fwd.hpp to libs/integer/include/boost/integer_fwd.hpp. It sees that it can symlink, so it assumes that the existing boost/integer_fwd.hpp is already a symlink and doesn't need to be updated. Your existing boost/integer_fwd.hpp is a file for some reason though. I don't know why. It's possible that when you originally ran b2 headers, it did not yet support symlinks, but that's just a guess, as I really don't know. This can be considered a bug in the part of Boost.Build that is responsible for the header links, but if it is, I don't know how or whether it should be fixed. Either way, if you delete your existing boost/ header directory and rerun b2 headers, the files there should now be symbolic links. I think.
My mental model has been that if I run these commands I am up to date on develop.
git checkout develop git pull --recurse-submodules git submodule update --init | added to check for new libraries. git submodule foreach git checkout develop git submodule foreach git pull | to bring everything up to date.
Yes, in theory. But there have been many occasions when the header copies/links do not update automatically, so it's still a problem from time to time.