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