Re: [boost] preprocess operation problems

Subject: Re: [boost] preprocess operation problems
From: Peter Dimov (lists_at_[hidden])
Date: 2015-01-28 13:07:58

Fletcher, John P wrote:
> These do not look like links to me:
>
> fletcher_at_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.