Michael Bieber

you should complain to the boost devs since they are the ones in control of that step. In this context, I am first and foremost using dlib. It is maybe (better, certainly) true, that boost has some responsibility here. But it won't help dlib a bit simply to know that. Realistically, boost will not change things in the near future (I was bringing up related issues there even as far back as 2005(?) ). Eventually taking charge and cutting the dependency seems to be the most sensible way to me, at least...

Boost's build process is for sure wack, however, you are telling me you aren't following the instructions. I use these instructions regularly to build on windows and they work without issue. You aren't going to get a lot of sympathy when you aren't following the instructions. I don't care that much about sympathy :) - but seriously, what I will convey here, is the bigger frame. For most people nowadays any library is only part of the whole picture. Boost unfortunately, is a central, basic module...

Boost's build process is for sure wack, however, you are telling me you aren't following the instructions. I use these instructions regularly to build on windows and they work without issue. You aren't going to get a lot of sympathy when you aren't following the instructions. I don't care that much about sympathy :) - but seriously, what I will convey here, is the bigger frame. For most people nowadays any library is only part of the whole picture. Boost unfortunately, is a central, basic module...

Boost's build process is for sure wack, however, you are telling me you aren't following the instructions. I use these instructions regularly to build on windows and they work without issue. You aren't going to get a lot of sympathy when you aren't following the instructions. I don't care that much about sympathy :) - but seriously, what I will convey here, is the bigger frame. For most people nowadays any library is only part of the whole picture. Boost unfortunately, is a central, basic module...

did you follow it's instructions? It sounds like you didn't. It shouldn't. As I mentioned in my first posting, I 've been trying all this and additional variants ad nauseum. You can also see this - at least in parts - in my logs. I have static boost python libraries - this requires the 2-step boost build mentioned above to be successful. I have set boost's hinting variables (correct boost headers have been found) address-model, runtime-link etc. (played even with 'link' and the possible combinations,...

Probably not very helpful (due to Boost_DEBUG not defined. I don't know how to pass this to setup.py). But be it (cf. attachment). IMO, the general problem lies in the intricacies of the boost build system. Most people have specialized 'installations' on Windows (also mine moves headers, libraries (import and static) as well as dll's around after compiling boost). CMake's FindBoost module was never in history fully able to embrace such deviations from his opaque preconditions - even slight and completely...

You only need to add BOOST_ROOT and BOOST_LIBRARYDIR. This has never worked for me. In the past, I fiddled with all the setup.py and immediate cmake build variants, in order to manage finally some Version '19.7.99' of the python bindings. The problem was always the naming convention of the boost libraries - not the header, these can always be found. Same is true for PyPI installations - now again for the recent 19.8.1. When I compile things for myself, current output (-DBoost_DEBUG=ON) is: -- [ V:/bin/cmake/standard/share/cmake-3.9/Modules/FindBoost.cmake:1618...