[boost] Build: Trying to get Boost.Build to see my OpenSSL on Windows

[Vinnie Falco]

I'm trying to build the Asio SSL examples but bjam can't find my
OpenSSL installation on Windows (using Visual Studio 2015). Everything
else builds. And I am having the dickens of a time finding any
information on the web about mixing Windows, OpenSSL, and bjam.

As a last resort I've thrown a hail mary to StackOverflow:
http://stackoverflow.com/questions/39800333/how-do-i-get-bjam-to-set-include-paths-for-openssl-headers-and-libraries-on-msvc

I'm not clear on what this line does on Windows using MSVC:

lib ssl ;

The line appears in Asio Jamfiles that use OpenSSL.

Any help is appreciated, thank you.

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

[degski]

On 1 October 2016 at 16:08, Vinnie Falco <vinnie...@gmail.com> wrote:

> I'm trying to build the Asio SSL examples but bjam can't find my
> OpenSSL installation on Windows (using Visual Studio 2015). Everything
> else builds.

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

And I am having the dickens of a time finding any
> information on the web about mixing Windows, OpenSSL, and bjam.

I would say they mix well.

degski

[Vinnie Falco]

On Sat, Oct 1, 2016 at 11:42 AM, degski <deg...@gmail.com> 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

[Steven Watanabe]

AMDG

On 10/01/2016 07:08 AM, Vinnie Falco wrote:
> I'm trying to build the Asio SSL examples but bjam can't find my
> OpenSSL installation on Windows (using Visual Studio 2015). Everything
> else builds. And I am having the dickens of a time finding any
> information on the web about mixing Windows, OpenSSL, and bjam.
>
> As a last resort I've thrown a hail mary to StackOverflow:
> http://stackoverflow.com/questions/39800333/how-do-i-get-bjam-to-set-include-paths-for-openssl-headers-and-libraries-on-msvc
>
> I'm not clear on what this line does on Windows using MSVC:
>
> lib ssl ;
>
> The line appears in Asio Jamfiles that use OpenSSL.
>

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

> Any help is appreciated, thank you.
>

In Christ,
Steven Watanabe

[Vinnie Falco]

On Sat, Oct 1, 2016 at 11:42 AM, degski <deg...@gmail.com> wrote:

> Check that you "told"...bjam...where OpenSSL can be found?

Is setup of a local site-config.jam the "standard" way to accomplish this?

See
http://www.boost.org/build/doc/html/bbv2/recipies/site-config.html

[Vinnie Falco]

On Sat, Oct 1, 2016 at 12:24 PM, Steven Watanabe <watan...@gmail.com> 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...

[Steven Watanabe]

AMDG

On 10/01/2016 10:33 AM, Vinnie Falco wrote:
> On Sat, Oct 1, 2016 at 12:24 PM, Steven Watanabe <watan...@gmail.com> 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

[Peter Dimov]

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?

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

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

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.

BTW2, the Asio example Jamfile does not do

lib ssl ;

under Windows. It does

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

[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]

On Sat, Oct 1, 2016 at 1:30 PM, Peter Dimov <li...@pdimov.com> wrote:
> BTW2, the Asio example Jamfile does not do
>
> lib ssl ;
>
> under Windows. It does
>
> lib ssl : : <name>ssleay32 ;
> lib crypto : : <name>libeay32 ;

True, although this just sets the correct filename for the library. It
doesn't help get the include path right.

My current approach is to try to get suitable "lib" entries in my
site-config.jam for ssl and crypto. From the Boost.Build docs, it
seems like there's a way to define a lib entry so that projects using
the lib will automatically inherit the proper include paths, library
paths, and library file names. Haven't quite got it right yet though.
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)
;

Still hacking on this trying to get it right...

[Peter Dimov]

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>?)

[Vinnie Falco]

On Sat, Oct 1, 2016 at 2:35 PM, Peter Dimov <li...@pdimov.com> 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

[Steven Watanabe]

AMDG

On 10/01/2016 12:40 PM, Vinnie Falco wrote:
> On Sat, Oct 1, 2016 at 2:35 PM, Peter Dimov <li...@pdimov.com> 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

[Vinnie Falco]

On Sat, Oct 1, 2016 at 2:45 PM, Steven Watanabe <watan...@gmail.com> 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:

file bin\msvc-14.0\debug\threading-multi\client.obj.rsp
"client.cpp" -Fo"bin\msvc-14.0\debug\threading-multi\client.obj"
-TP /Z7 /Od /Ob0 /W3 /GR /MDd /Zc:forScope /Zc:wchar_t /wd4675 /EHs -c
-DBOOST_ALL_NO_LIB=1
-DBOOST_SYSTEM_DYN_LINK=1
-D_WIN32_WINNT=0x0501
"-ID:\lib\boost_1_61_0"
compile-c-c++ bin\msvc-14.0\debug\threading-multi\client.obj

call "C:\Users\Vinnie\AppData\Local\Temp\b2_msvc_14.0_vcvarsall_x86.cmd"
>nul
cl /Zm800 -nologo @"bin\msvc-14.0\debug\threading-multi\client.obj.rsp"

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.

> Also, to access environmental variables,
> use [ os.environ OPPENSSL_LIBRARIES ]. You'll
> need to add import os to call this.

Yep, that all works - thanks for confirming!

[Steven Watanabe]

AMDG

On 10/01/2016 12:50 PM, Vinnie Falco wrote:
> On Sat, Oct 1, 2016 at 2:45 PM, Steven Watanabe <watan...@gmail.com> 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

[Peter Dimov]

Vinnie Falco wrote:
...

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

This Jamfile works for me:

OPENSSL_ROOT = C:/Projects/ladym-svn/trunk/src/ladym/openssl-1.0.2d ;
OPENSSL_INCLUDE = $(OPENSSL_ROOT)/include ;
OPENSSL_LIB = $(OPENSSL_ROOT)/lib ;

lib ssl
:
: <name>ssleay32MT
:
: <include>$(OPENSSL_INCLUDE) <library-path>$(OPENSSL_LIB)
;

lib crypto
:
: <name>libeay32MT
:
: <include>$(OPENSSL_INCLUDE) <library-path>$(OPENSSL_LIB)
;

lib user32 ;
lib gdi32 ;
lib advapi32 ;
lib ws2_32 ;

exe client : client.cpp : <library>ssl <library>crypto <library>ws2_32
<library>user32 <library>gdi32 <library>advapi32 ;

where client.cpp is

#include <openssl/ssl.h>

int main()
{
OpenSSL_add_all_algorithms();

SSL_load_error_strings();
SSL_library_init();

[Vinnie Falco]

On Sat, Oct 1, 2016 at 3:10 PM, Peter Dimov <li...@pdimov.com> 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 <watan...@gmail.com> 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

[Steven Watanabe]

AMDG

On 10/01/2016 02:55 PM, Vinnie Falco wrote:
>
> 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.
>

The Jamfile isn't really designed to support it.

> On Sat, Oct 1, 2016 at 3:00 PM, Steven Watanabe <watan...@gmail.com> 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).
>

You can set them in user-config with the 'project'
rule. The only problem is that they will be used
for all builds of everything, regardless of whether
they're actually needed. I suppose that you could
put a project-config.jam in the directory of the
ssl example. This will be used only when you
run b2 in that directory.

In Christ,
Steven Watanabe

[Peter Dimov]

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.

[Vinnie Falco]

On Sat, Oct 1, 2016 at 6:05 PM, Peter Dimov <li...@pdimov.com> wrote:
> 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.

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.

Is there a pointer to the Boost.Build docs that describe the use of
these variables?

[degski]

On 2 October 2016 at 03:12, Vinnie Falco <vinnie...@gmail.com> 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

[Peter Dimov]

Vinnie Falco wrote:
> On Sat, Oct 1, 2016 at 6:05 PM, Peter Dimov <li...@pdimov.com> wrote:
> > 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.
>
> 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.
>
> Is there a pointer to the Boost.Build docs that describe the use of these
> variables?

These variables aren't Boost.Build's, they are MSVC-specific, cl.exe uses
them. But they are being set by the vcvars32.bat file that b2 calls to set
up the cl.exe environment, so any previous values you have will be lost.

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.

So at this point I have no idea how the Asio Jamfile was supposed to work
under Windows.

[Steven Watanabe]

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

[Peter Dimov]

Steven Watanabe wrote:
> 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.

Thanks!

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?

[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

[Vinnie Falco]

On Sun, Oct 2, 2016 at 2:17 PM, Steven Watanabe <watan...@gmail.com> wrote:
> 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 ;

We have liftoff! I built Asio's SSL example with these lines in my
site-config.jam:

import os ;
using msvc ;
local OPENSSL_ROOT = [ os.environ OPENSSL_ROOT ] ;
project
: requirements
<include>$(OPENSSL_ROOT)/include
<library-path>$(OPENSSL_ROOT)/lib
;

Thanks everyone for helping me slog through this

[degski]

On 2 October 2016 at 19:59, Steven Watanabe <watan...@gmail.com> 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

[Peter Dimov]

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.

[Vinnie Falco]

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.

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

[Steven Watanabe]

AMDG

On 10/07/2016 08: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.
>
> 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.
>

In principle usage would look like this:

using openssl ;
The library can then be referenced with /openssl//openssl.

Of course, openssl.jam doesn't actually exist right now.

There are only a few libraries supported this
way right now, including zlib and bzip2 (used
by IOStreams).

In Christ,
Steven Watanabe

[Rene Rivera]

On Fri, Oct 7, 2016 at 9:06 AM, Vinnie Falco <vinnie...@gmail.com> 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

[Vinnie Falco]

On Fri, Oct 7, 2016 at 10:32 AM, Rene Rivera <grafi...@gmail.com> wrote:
> ...

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

This is definitely not the fault of CMake, because OpenSSL decided to
rename all their libraries starting with 1.1.0. Perhaps because the
APIs are no longer backward compatible (?)

[Edward Diener]

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.

[Vinnie Falco]

On Fri, Oct 7, 2016 at 2:30 PM, Edward Diener <eldi...@tropicsoft.com> 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

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

[Paul Fultz II]

> On Oct 7, 2016, at 8:06 AM, Vinnie Falco <vinnie...@gmail.com> 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.
>
> 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

Unfortunately, its broken when using with pkgconfig on windows, with this:


if (UNIX)
find_package(PkgConfig QUIET)
pkg_check_modules(_OPENSSL QUIET openssl)
endif ()

It should try to find it with pkgconfig first and then fallback to guessing.

Paul

[Vinnie Falco]

On Fri, Oct 7, 2016 at 3:29 PM, Paul Fultz II <pfu...@yahoo.com> 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.

[Paul Fultz II]

> On Oct 7, 2016, at 1:36 PM, Vinnie Falco <vinnie...@gmail.com> wrote:
>
> On Fri, Oct 7, 2016 at 3:29 PM, Paul Fultz II <pfu...@yahoo.com> 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

[Vinnie Falco]

On Fri, Oct 7, 2016 at 6:32 PM, Paul Fultz II <pfu...@yahoo.com> 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).

[Edward Diener]

On 10/7/2016 2:51 PM, Vinnie Falco wrote:
> On Fri, Oct 7, 2016 at 2:30 PM, Edward Diener <eldi...@tropicsoft.com> 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.