On Sat, Oct 1, 2016 at 11:42 AM, degski wrote:

Check that you "told" either bjam or the "Visual Studio Command Prompt" the location where OpenSSL can be found?

I have these lines in my .bashrc (I use the bash shell that comes with Git for Windows) export OPENSSL_ROOT=/d/lib/openssl/ export OPENSSL_ROOTDIR=/d/lib/openssl/ export OPENSSL_INCLUDE_DIR=/d/lib/openssl/include export OPENSSL_LIBRARIES=/d/lib/openssl/lib Could you please guide me to a resource on the web explaining the correct configuration of OpenSSL on Windows for building with Boost.Build? Regards

AMDG On 10/01/2016 10:33 AM, Vinnie Falco wrote:

On Sat, Oct 1, 2016 at 12:24 PM, Steven Watanabe wrote:

...

... It assumes that ssl can be found in the default library path. You should be able to pass the paths to Boost.Build with b2 library-path=... include=...

Wow, that's a huge hassle. And that doesn't scale, what if a project uses 5 different libraries? You have to pass 10 command line options? That's incredibly inconvenient... surely this is not the recommended approach to finding library dependencies...

No it isn't. This is really a workaround for the user when the author of the Jamfile decided to be lazy. You can also put them in a config file (user-config.jam, site-config.jam, or project-config.jam) like this: project : requirements <library-path>... <include>... ; A better way is to create a module like tools/zlib.jam. In Christ, Steven Watanabe

AMDG On 10/01/2016 11:30 AM, Peter Dimov wrote:

Steven Watanabe wrote:

...

...

That's incredibly inconvenient... surely this is not the recommended approach to finding library dependencies...

No it isn't. This is really a workaround for the user when the author of the Jamfile decided to be lazy. ... A better way is to create a module like tools/zlib.jam.

Is it really fair to blame the author of the Jamfile for the lack of tools/ssl.jam?

No, probably not. It should at least allow configuration through environmental variables, though.

Besides, a module is probably best when we want to support building the library from source, but OpenSSL is pretty hard to build (and, I think, CMake based), so I doubt that anyone would volunteer to translate its build script (or, for extra fun, the build scripts for each of its releases).

Building from source is really only viable for simple libraries. There are several other reasons for writing a module: - Configuring the library from user-config.jam is using ssl : [various options] ; which is consistent with everything else. - The code for finding the library doesn't need to be duplicated if it's needed in multiple places.

I don't think that the recommended approach for finding an arbitrary preinstalled library should be "write a module".

If there's any significant logic beyond just lib xxx, (and possibly getting a path from an environmental variable) I don't think that factoring it into a separate module is a significant extra burden. I know that there's a fair amount of code in zlib.jam, but most of it is error checking, messages for --debug-configuration, and support for building from source.

By looking around, I can deduce that ac.check-library was probably intended to be the way to do that, but it doesn't appear to be documented.

BTW libtiff.jam and libjpeg.jam look for ZLIB_SOURCE. I assume this is a typo, because libpng.jam looks for LIBONG_SOURCE.

Definitely.

BTW2, the Asio example Jamfile does not do

lib ssl ;

under Windows. It does

lib ssl : : <name>ssleay32 ; lib crypto : : <name>libeay32 ;

In Christ, Steven Watanabe

Vinnie Falco wrote:

Here are my site-config.jam entries:

lib ssl : # sources : # requirements <name>ssleay32MT : # default-build : # usage-requiremnets <include>$(OPENSSL_INCLUDE_DIR) ;

lib crypto : : <name>$(OPENSSL_LIBRARIES)/VC/libeay32MT : : <include>$(OPENSSL_INCLUDE_DIR) ;

This looks like it should work, but <name> should probably be just libeay32MT and $(OPENSSL_LIBRARIES)/VC probably needs to go into the usage requirements as whatever property would do -L (<library-path>?)

AMDG On 10/01/2016 12:40 PM, Vinnie Falco wrote:

On Sat, Oct 1, 2016 at 2:35 PM, Peter Dimov wrote:

...

Vinnie Falco wrote:

...

Here are my site-config.jam entries: ... This looks like it should work

Thanks for looking at it. Its not seeing the include path so I am getting an error "can't find file openssl/conf.h" when building. I'm trying all sorts of things, including <include>D:\lib\openssl\include

'\' is an escape character. Use '/' or '\\' Also, to access environmental variables, use [ os.environ OPPENSSL_LIBRARIES ]. You'll need to add import os to call this. In Christ, Steven Watanabe

AMDG On 10/01/2016 12:50 PM, Vinnie Falco wrote:

On Sat, Oct 1, 2016 at 2:45 PM, Steven Watanabe wrote:

...

'\' is an escape character. Use '/' or '\\'

This entry:

lib ssl : # sources : # requirements <name>ssleay32MT <include>x : # default-build <include>x : # usage-requirements <include>x ;

Produces this output:

<snip> client.cpp D:\lib\boost_1_61_0\boost/asio/ssl/detail/openssl_types.hpp(19): fatal error C1083: Cannot open include file: 'openssl/conf.h': No such file or directory

Notice how "x" doesn't even appear on the command line.

However, if I do something like put the <include> line in the sources section, I get an error "property found in sources" - this tells me that the site-config.jam is being loaded and processed. Its just that the include property is not being applied to the resulting build commands.

I suspect that the reason is that your lib ssl is not being used. Keep in mind that targets are scoped within a project. A lib ssl in user-config.jam is totally separate from a lib ssl in your Jamfile. To access it you'll need to add project user-config ; in user-config.jam and then refer to /user-config//ssl in the Jamfile. (The name in the project declaration doesn't have to be user-config. It will work as long as it matches the project name in the target reference.) In Christ, Steven Watanabe

On Sat, Oct 1, 2016 at 3:10 PM, Peter Dimov wrote:

This Jamfile works for me: ...

Yep, that worked for me as well. But I'm trying to get Boost.Asio's SSL examples to build for me using MSVC, and of course I shouldn't have to modify its Jamfile: https://github.com/boostorg/asio/blob/develop/example/cpp03/ssl/Jamfile.v2 My assumption during this whole process is that with a correctly configured MSVC/Boost.Build environment, I can get the Asio SSL examples to compile simply by issuing "b2" from the corresponding directory. I am starting to believe this assumption is false. On Sat, Oct 1, 2016 at 3:00 PM, Steven Watanabe wrote:

I suspect that the reason is that your lib ssl is not being used.

Yes I am believing that as well!

A lib ssl in user-config.jam is totally separate from a lib ssl in your Jamfile. To access it you'll need to add project user-config ; in user-config.jam and then refer to /user-config//ssl in the Jamfile

This is producing results! I am making forward progress now. But I'm still left wondering how anyone is supposed to build the Asio SSL example on Windows (without having to add a bunch of paths to the b2 invocation every time). Thanks

Vinnie Falco wrote:

But I'm still left wondering how anyone is supposed to build the Asio SSL example on Windows (without having to add a bunch of paths to the b2 invocation every time).

Based on how it's written, the expectation is probably that the INCLUDE and LIBPATH environment variables contain the appropriate OpenSSL directories. That's the closest thing on Windows to "system" include/library paths.

On 2 October 2016 at 03:12, Vinnie Falco wrote:

That sounded promising so I set these variables in the environment but I'm still not having any luck building the SSL Asio examples on Windows. The environment variables have no effect on the build output.

I'm working on the assumption that you want to use cl.exe as your compiler. If you open a VS20XX Command Prompt (elevated), you can add the paths to your libs in that environment like this: INCLUDE=%INCLUDE%;d:\vf_libs\include PATH=%PATH%;d:\vf_libs\lib Now cl.exe will be able to find your includes/libs, independently from bjam. Issue a "set" command and you'll be able to see all the settings, it's pretty self explanatory. For all info on cmd-shell, take a look at ss64.com. It's also good for bash/powershell/OSX... Now issue the proper bjam command (for building the asio examples) and things should work. degski

AMDG On 10/02/2016 05:54 AM, Peter Dimov wrote:

Things are further complicated by the fact that Boost.Build no longer actually uses Visual Studio's vcvars32.bat file, it generates its own in %TMP%.

I looked at tools/build/src/tools/msvc.jam to try to figure out what it does, without much success.

Boost.Build runs vcvars32.bat once, calculates the changes that it made to the environment, and writes its own batch script that makes the same changes. The reason for this is that on some version of msvc, running vcvars32.bat on every compiler invocation causes a noticeable slowdown. In Christ, Steven Watanabe

AMDG On 10/02/2016 11:13 AM, Peter Dimov wrote:

And, to get back to the problem at hand, is there something that one can put into user-config.jam or site-config.jam to set the global 'include' and 'library-path' instead of passing them on the command line?

Yes. Any properties can be set at the project level by the project rule: project : requirements <library-path>/x/y/z <include>/a/b/c ; These requirements are inherited by subprojects and since user-config is the parent project of Jamroot, if you put this in user-config, it will affect all projects. In Christ, Steven Watanabe

On 2 October 2016 at 19:59, Steven Watanabe wrote:

Boost.Build runs vcvars32.bat once, calculates the changes that it made to the environment, and writes its own batch script that makes the same changes.

I'm happy the cat is out of the bag. 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, while still addressing the concerns relating to build-speed. This is AFAICS also the approach that cmake takes, cmake has to be invoked from a vs prompt. Have a good day, degski

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. 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.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- Follow me on Github: https://github.com/vinniefalco

On Fri, Oct 7, 2016 at 9: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.

If it where truly easy it would work regardless of version ;-)

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.

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.

We have at least two. I used to maintain a set of "extensions" for libraries that could be built from their sources (or some binaries) < https://svn.boost.org/svn/boost/sandbox/tools/build_extensions/ext/>. Not sure if that still works, but it probably does. And for projects that already have Boost Build as the build system there's also the "modular" utility < https://github.com/boostorg/build/blob/develop/src/contrib/modular.jam>. It lets you put something like this in your Jamroot (or any other project file like user-congi.jam): === import modular ; modular.add-location libs/boost /boost ; modular.external /boost/system : /boost/config//library /boost/assert//library /boost/core//library ; modular.external /boost/config : /boost/predef//library ; modular.external /boost/filesystem : /boost/type_traits//library /boost/iterator//library /boost/smart_ptr//library /boost/io//library /boost/functional//library /boost/range//library ; modular.external /boost/type_traits : /boost/mpl//library /boost/detail//library ; modular.external /boost/mpl : /boost/preprocessor//library ; modular.external /boost/iterator : /boost/static_assert//library ; modular.external /boost/smart_ptr : /boost/throw_exception//library ; === And then you can reference in your b2 targets dependencies to "/boost/smart_ptr//library/<link>static" for example. And of course you can write your own custom support for anything using the regular "using" mechanism of b2. For example < https://github.com/boostorg/build/blob/develop/src/tools/zlib.jam>. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

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.

On 10/7/2016 2:51 PM, Vinnie Falco wrote:

On Fri, Oct 7, 2016 at 2:30 PM, Edward Diener wrote:

...

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

Code distinguishing the library address model is here: https://github.com/Kitware/CMake/blob/master/Modules/FindOpenSSL.cmake#L124

That is very nice for OpenSSL but what about other packages ? For a 64-bit build the find_package(libxml2) finds the 32-bit libxml2 library and says that it has found the right package. I experience this when using CMake to build a 64-bit version of clang. I still don't think CMake's find_package command in general can distinguish between 32-bit and 64-bit packages of libraries or even knows which bit-ness it needs to find when executing the command. But again this is off-topic. All I am trying to say that instead of trying to claim that CMake does this and that as opposed to Boost Build you, and others, would be much be much better off to stop trying to suggest how good CMake is and just focus on how to do things with Boost Build if that is really what you want to know.

...

I concluded...that CMake could not do so.

I tested it, and it works great for both 32 and 64 bit executable targets. You do have to run both OpenSSL installers.

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. 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...) However, CMake's FindOpenSSL does handle the most common use case - when OpenSSL is brought in using its installer. 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.

On Fri, Oct 7, 2016 at 6:32 PM, Paul Fultz II wrote:

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.

Hmm... I'm not sure that is helpful for me - I need bjam to work without cmake, so that my library builds correctly as part of Boost (which currently, does not require cmake).