Quantcast

missing symbolic link during build

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

missing symbolic link during build

Stefan Seefeld-2
Hi,


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.

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 ?

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

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.)

Thanks,
        Stefan

--

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: missing symbolic link during build

Steven Watanabe-4
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: missing symbolic link during build

Stefan Seefeld-2
On 23.01.2017 20:34, Steven Watanabe wrote:

> 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.


OK, that worked, thanks.

>> 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.

What project do these files belong to, i.e. where should I report this
as a bug ?
>> 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.

What if I want to reproduce the original (i.e., pristine) state of the
source tree ? Do I have to remove the links manually ?

>> 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.)

It sounds like you have given up on the Boost modularization effort.

        Stefan

--

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: missing symbolic link during build

Steven Watanabe-4
AMDG

On 01/23/2017 10:54 PM, Stefan Seefeld wrote:

> On 23.01.2017 20:34, Steven Watanabe wrote:
>>  <snip>
>> 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.
>
> What project do these files belong to, i.e. where should I report this
> as a bug ?

utility

>> <snip>
>>   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.
>
> What if I want to reproduce the original (i.e., pristine) state of the
> source tree ? Do I have to remove the links manually ?

You can just delete the boost/ directory.

> <snip>
> It sounds like you have given up on the Boost modularization effort.
>

  I never cared about modularization in the
first place.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: missing symbolic link during build

Stefan Seefeld-2
On 24.01.2017 10:06, Steven Watanabe wrote:

> AMDG
>
> On 01/23/2017 10:54 PM, Stefan Seefeld wrote:
>> On 23.01.2017 20:34, Steven Watanabe wrote:
>>>  <snip>
>>> 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.
>> What project do these files belong to, i.e. where should I report this
>> as a bug ?
> utility
>
>>> <snip>
>>>   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.
>> What if I want to reproduce the original (i.e., pristine) state of the
>> source tree ? Do I have to remove the links manually ?
> You can just delete the boost/ directory.
>
>> <snip>
>> It sounds like you have given up on the Boost modularization effort.
>>
>   I never cared about modularization in the
> first place.

Gotta love a direct and honest answer...

        Stefan


--

      ...ich hab' noch einen Koffer in Berlin...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Loading...