On Fri, Sep 29, 2023 at 11:24 AM Peter Dimov via Boost < boost@lists.boost.org> 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/0d58357ab9eeaa6ad064193bed7280a8...
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/0d58357ab9eeaa6ad064193bed7280a8...
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? If anyone needs access to this environment (i.e. have ideas but not a windows environment), I can give remote desktop credentials for a test machine. Tom