Re: [Boost-build] missing symbolic link during build

Subject: Re: [Boost-build] missing symbolic link during build
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-01-23 20:34:10

AMDG

On 01/23/2017 01:49 PM, Stefan Seefeld wrote:
> 
> I'm running into a build failure that I'm not fully understand, so let
> me describe what I ended up in this situation:
> 
> 
> I'm working on a Linux machine, using a full (modular) boost repo. I
> have started a Windows VM and mounted the directory containing the repo
> there.
> 

  This can be a bit tricky depending on the details.
In particular, if the host and the VM don't agree
about whether they can create symbolic links, then
you need to make sure that all the links are always
created from the host side.  Before I build in a VM,
I always run `b2 headers` on the host first.

> When I'm running b2 on Windows, I eventually get the error
> 
>   .\boost/preprocessor/iteration/detail/iter/forward1.hpp(47): fatal
> error C1083: Cannot open include file:
> 'boost/utility/detail/result_of_iterate.hpp': No such file or directory
> 
> I see that everything inside boost/utility/ is a symbolic link to
> libs/utility/include/... However, the 'boost/utility/detail/' directory
> is missing there, leading to the above error.
> 
> 
> Any idea how that could happen ? Speculating: is it possible that on
> Linux that link isn't needed, so is left out (after all, I'm able to
> build on Linux without errors), but on Windows the link is needed, but
> b2 discovered that (some) links already existed, and thus skipped that
> build step ?
> 

It's probably missing because it isn't found by the #include scanner.
(the easiest way to fix this is to add
#if 0
#include <boost/utility/detail/result_of_iterate.hpp>
#endif
in result_of.hpp.

> How can I clean up my (source) tree, i.e. remove the links, so that
> running b2 would be forced to regenerate them ?
> 

  You can just run `b2 headers` at the root of
the boost tree to generate all links.  You don't
need to delete the existing links first.

> And, to step back a step: why are these links generated to begin with ?
> Can't they be avoided by adding a bunch of include paths ? (I'd argue
> that using explicit include paths is better as it helps the
> modularization effort.)
> 

a) This is almost guaranteed to overrun command line length
   limitations, if you're not using rsp files.
b) It makes manual compiler invocation for users of boost
   incredibly annoying.  (It would essentially be impractical
   to invoke the compiler without using some tool to determine
   all the correct #include paths.)

In Christ,
Steven Watanabe