On 10/7/2016 10:06 AM, Vinnie Falco wrote:
I just got CMake working to find my OpenSSL installation and let me tell you, it was a breeze. First of all you need to install OpenSSL for Windows. I used 1.0.2j. The 1.1.0 series doesn't work since they changed all the filenames around.
Then you just add this line to your CMakeLists.txt: find_package(OpenSSL)
WHAT!? That's it? Yeah. It should be this easy in a Jamfile. You can have both 32 and 64 bit OpenSSL libraries installed. And it correctly links against the debug libraries if you are building a debug executable.
I once asked on the CMake user's mailing list how CMake distinguishes between a 32-bit or a 64-bit package when the find_package command was used and received no reply whatsoever. I concluded from my "answer" that CMake could not do so. So your comment "WHAT!? That's it? Yeah." does not impress me as much as your comment no doubt intends it to do.
How does CMake do it? There's a nifty little program called FindOpenSSL. The source is here: https://github.com/Kitware/CMake/blob/master/Modules/FindOpenSSL.cmake
I'm wondering, does Boost.Build already have such a system? And if not, could it be done? How would something like that look? I'm interested in exploring the possibilities here.
On Mon, Oct 3, 2016 at 6:35 AM, Peter Dimov
wrote: degski wrote:
This seems very wrong to me, and the fact that this thread exists, proves it. It seems to me that the environment should be taken from environment set in the command shell from which bjam is run at the first invokation, as that is the environment that the user has created/selected. This gives maximum flexibility, ...
People often forget that Boost.Build supports building more than one configuration at a time.
b2 toolset=gcc,clang,msvc-8.0,msvc-9.0,msvc-10.0,msvc-11.0,msvc-12.0,msvc-14.0
You can't set up a correct environment for this beforehand.