Re: Windows Regression Runners - Failing on Develop

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-10-02 01:34:10

On 10/2/23 03:03, Tom Kent via Boost wrote:
> On Fri, Sep 29, 2023 at 11:24 AM Peter Dimov via Boost <
> boost_at_[hidden]> wrote:
> 
>>> Steven Watanabe wrote:
>>>> When b2 fails to create a symlink it's usually because the header is
>>>> only included through a macro, and the #include scanner misses it.
>>>
>>> That was my first thought, but it's a normal include:
>>>
>>> https://github.com/boostorg/filesystem/blob/0d58357ab9eeaa6ad064193be
>>> d7280a894a06726/src/platform_config.hpp#L74
>>>
>>> It might have to do something with the fact that platform_config.hpp
>>> is in src/; not sure how this gets into the include path.
>>
>> Here:
>>
>>
>> https://github.com/boostorg/filesystem/blob/0d58357ab9eeaa6ad064193bed7280a894a06726/config/Jamfile.v2#L40
>>
>>> https://github.com/boostorg/filesystem/blob/0d58357ab9eeaa6ad064193be
>>> d7280a894a06726/config/has_bcrypt.cpp#L9
>>>
>>> But boost/winapi/config.hpp is also included directly from the config
>>> check source:
>>>
>>> https://github.com/boostorg/filesystem/blob/0d58357ab9eeaa6ad064193be
>>> d7280a894a06726/config/has_bcrypt.cpp#L17C11-L17C34
>>>
>>> so the include scanner must be able to see it anyway.
>>>
>>> boost/winapi is a junction/symlink for me, so it's not the split either.
>>
>> Further experimentation reveals that the header links are correctly created
>> when I try to build the has_bcrypt exe directly:
>>
>> C:\boost-git\develop>rd/s/q boost
>>
>> C:\boost-git\develop>b2 libs/filesystem/config//has_bcrypt
>> Performing configuration checks
>>
>>     - default address-model    : 64-bit (cached) [1]
>>     - default architecture     : x86 (cached) [1]
>>     - symlinks supported       : yes (cached)
>>
>> [1] msvc-14.3
>> ...found 40 targets...
>> ...updating 7 targets...
>> mklink-or-dir boost
>> mklink-or-dir boost\predef
>> symbolic link created for boost\predef <<===>>
>> ..\libs\predef\include\boost\predef
>> mklink-or-dir boost\winapi
>> symbolic link created for boost\winapi <<===>>
>> ..\libs\winapi\include\boost\winapi
>> mklink-or-dir boost\filesystem
>> symbolic link created for boost\filesystem <<===>>
>> ..\libs\filesystem\include\boost\filesystem
>> link.mklink boost\config.hpp
>> symbolic link created for boost\config.hpp <<===>>
>> ..\libs\config\include\boost\config.hpp
>> mklink-or-dir boost\system
>> symbolic link created for boost\system <<===>>
>> ..\libs\system\include\boost\system
>> mklink-or-dir boost\detail
>> mklink-or-dir boost\config
>> symbolic link created for boost\config <<===>>
>> ..\libs\config\include\boost\config
>> link.mklink boost\detail\workaround.hpp
>> symbolic link created for boost\detail\workaround.hpp <<===>>
>> ..\..\libs\config\include\boost\detail\workaround.hpp
>> ...patience...
>> link.mklink boost\version.hpp
>> symbolic link created for boost\version.hpp <<===>>
>> ..\libs\config\include\boost\version.hpp
>> compile-c-c++
>> bin.v2\libs\filesystem\config\msvc-14.3\debug\threading-multi\has_bcrypt.obj
>> has_bcrypt.cpp
>> msvc.link
>> bin.v2\libs\filesystem\config\msvc-14.3\debug\threading-multi\has_bcrypt.exe
>> ...updated 13 targets...
>>
>> So it's only when it's being built by configure.builds:
>>
>>
>> https://github.com/boostorg/filesystem/blob/0d58357ab9eeaa6ad064193bed7280a894a06726/build/Jamfile.v2#L39
>>
>> are the headers not being linked.
>>
> 
> Sometime this morning, this seems to have migrated to master as well as
> develop.
> 
> There was a bit of conversation about symlinks, but I'm not sure that those
> are ever being made on this machine, as windows has some weird rules about
> what users can make them. Failing that, does it make copies?

Yes, it should copy the headers if symlinks cannot be created. But, if
Peter is correct, the problem is not that it can't create the symlinks.
The problem is that Boost.Build doesn't track headers required by
configure checks.

I think the regression testing scripts should be running `b2 headers`
before building anything. Automatic creation of the unified include tree
has never worked reliably, so `b2 headers` is a mandatory step after git
checkout.

IMHO, the automatic creation of symlinks should be removed, as it's not
useful and just wastes build time.