The Boost install in my vcpkg setup has [core] instead of [icu], that should have been built against icu.
My Boost install command was: vcpkg install boost:x64-windows boost:x64-windows-static boost:x86-windows
I wanted to make sure I got the Windows triplet installed correctly, I'm a "it works this way though probably not the best or easiest method" kinda guy, and it installed a butt-load of Boost libraries. As it should have.
Installing the upper level Boost did the --recurse option as part of the install process for all the libraries.
A while back I added a special system-wide environment variable so vcpkg didn't retain the binary caches since I am a lone self-taught hobbyist developer. It is enabled by default.
If you don’t want to use binary caching, you can turn it off by setting the environment variable VCPKG_FEATURE_FLAGS to -binarycaching (including the minus). You can alternatively pass the --no-binarycaching option on the command line.
vcpkg is updated periodically, running an outdated version can cause problems with keeping the installed libraries up to date. There is a special bat file for updating the local versions of the app. bootstrao-vcpkg.bat. I run the bat file after I do a git pull and then run the batch with the -disableMetrics options.
(I had copied the static boost lib directly to the compile directory.)
The file runs, and does things correctly!
I still can’t quite get CMake to behave here, though.
But while this is fabulous, I cannot verify that the system icu.dll is being used by the Boost Locale library (the one in C:\Windows\System32). It is not directly required by collate.exe’s dependencies, which I figure it ought to be were the static libboost_locale requiring it...
Dependency Walker hangs for me on this program, and dumpbin is just a deep deep rabbit hole of dependency hocky sticks.
(I also tried to look through the non-static boost locale DLL.)
Currently running the Boost Locale example “boundary.cpp” program indicates that the generated locale does not have word-boundary boundary analysis, which it should were it properly linked to ICU!
Yeah, there’s plenty of awesome software out there that flies past my radar these days. I’m too old to keep up on it all any more.
Vcpkg packages link with plenty of Windows DLLs.
It’s just that its boost-locale[icu] compilation did not link with Windows’s copy of ICU.
The reason it matters is because the ICU data base is massive, and the DLLs aren’t tiny either. But every modern system (Win, Linux, Mac, iOS, Android, etc) all have a bundled copy of ICU available and running on it, to which I figure my software ought to bind instead of just adding bloat.
But playing with Boost configuration scripts is Not What I Want To Do, alas. We’ll see what I wind up doing, I guess. I’ll keep y’all posted.
The amusing part of this discussion about vcpkg is I have (for me) a number of 3rd party libraries installed via vcpkg, Boost (all of it) is one of them, but I rarely use any of the libraries I've installed. Only recently did I use SFML very briefly because of a "Learn C++" book I purchased that is all about creating graphical games using the library I was plinking with.
Do I care about how the libraries binaries are built? "Easy for you, difficult for me" might be my response. :) vcpkg works, and works very well, for this self-taught C++ hobbyist.
But yet again, D, you educate me about something I had never thought about. And done it in a manner that didn't talk down or sneeringly insult. Thanks for the easily digestible lecture on ICU. :D