On Oct 7, 2016, at 1:36 PM, Vinnie Falco
wrote: On Fri, Oct 7, 2016 at 3:29 PM, Paul Fultz II
wrote: Unfortunately, its broken when using with pkgconfig on windows, with this: ... It should try to find it with pkgconfig first and then fallback to guessing.
I have never used pkgconfig on Windows, or even heard of it until now. It sounds like a Unix tool that was brought over to Windows to make non-natives feel more at home.
Either way, OpenSSL generates pkgconfig when building for windows.
Speaking only for myself, if I was the maintainer of CMake it would be impractical to support every single package manager. (conan, vcpkg, nuget, etc…)
CMake doesn’t support any package managers. I am talking about package configuration, and there are only two widely-used package configurations systems: CMake and pkgconfig. Both are cross-platform and both can be used with any build system(although its rare to find non-cmake build systems using cmake’s package configuration). As with libraries that aren’t built with cmake, it is quite common for it to only generate pkgconfig, which is what OpenSSL does. CMake then provides its own package module to search for the pkgconfig or make guesses at possible common use cases. Boost.Build can do the same, and provide a bjam file to find openssl, but since Boost.Build is only used within a small portion of the boost community, the community support is not there for things like that.
However, CMake's FindOpenSSL does handle the most common use case - when OpenSSL is brought in using its installer.
The point of a package configuration system is for it to always work, not just in possible common use cases.
Now that CMake is squared away for my Beast SSL examples, I'm trying to get the bjam based build sorted. And having similar troubles...there's no "find OpenSSL" in bjam.
Can you just call cmake from bjam to get the configuration, like `cmake --find-package -DNAME=OpenSSL`? The only issue with that you would need to translate the bjam toolchain to the cmake toolchain. Although its not helpful to you, boost really should move to cmake, and away from Boost.Build since there is very little community support for it compared to cmake. Paul