Re: [Boost-build] Locating libraries

Subject: Re: [Boost-build] Locating libraries
From: Brian Ravnsgaard Riis (brian_at_[hidden])
Date: 2012-01-05 19:35:45

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05-01-2012 16:27, Mateusz Loskot wrote:
> I have been trying to figure out how to achive such thing myself. 
> And for some reasons I failed, so I moved myself from Boost.Build
> to...CMake (though, I'd not advocate for CMake against Boost.Build
> :))
> 
> However, what I found useful is Boost Build Extensions project
> 
> http://svn.boost.org/svn/boost/sandbox/tools/build_extensions/
> 
> announced by Volodya some time ago:
> 
> http://lists.boost.org/Archives/boost/2010/10/171618.php

Yes, I am familiar with this part of the sandbox (which I stumbled
upon quite by accident several years ago). The build_extensions
project is designed to allow building of software packages that do not
use BB as a part of your own software build process. This is very
nice, and besides this project taught me *a lot* about the internals
of b2. (Trying to "reverse engineer" extensions.jam and wxwidgets.jam
in order to simply figure out what is going on is a great way to
learn, if occassionally somewhat painful.)

> 
> I used these extensions during Boost.GIL review to manage
> dependencies of raster libraries like libpng, etc. Here you can
> find some of my notes:
> 
> http://mateusz.loskot.net/2010/10/17/notes-on-boost-build-for-boost-gil/
>
> 
http://mateusz.loskot.net/2010/11/02/updating-boost-build-extensions/
> 
> If anyone knows a better approach than Boost.Build extensions, I'd
> love to hear.

I think the b2 extensions project (or something like it) is quite good
for projects that do not use b2. We then need a repository of jamfiles
corresponding to a wide set of software projects: zlib, png, jpeg,
pango, freetype, wxWidgets, you-name-it.

Unfortunately, since these are for projects that do *not* use b2
internally, someone needs to keep the jamfiles in this repository
up-to-date...

But what about pre-built libs? A given piece of software may be quite
able to compile and run without, say, freetype or pango, but take
advantage of these libraries if they are present. If b2 could
determine whether they are available it could configure that build
correspondingly.

Even better, it might be possible to have b2 locate headers and
libraries (or even complete software packages) given some standard
locations (and some supplied non-standard?) to search for the files
in. This is what CMake's FIND_PATH and FIND_LIBRARY commands do.

Just thinking out loud here...

A couple of problems/issues I see could be that the library is already
defined when we start looking for it. Say there is a site-config.jam
containing (from the manual):

    lib z ;
    lib png : z : <name>png ;

A given "find-library z" (or whatever the syntax might be) should then
return immediately since it's already defined, no? But is it possible
to determine in b2 that a given target has already been defined? And
how should it return success or failure? I would assume that if it
found zlib it would define z appropriately (tacking on the appropriate
<include> and <searched-lib> properties), but how to report that it
did not find it? As per above it can't simply stop the build process,
because we /might/ be able to continue regardless (possibly emitting a
warning).

Is any of all this at all possible in b2 at Jamfile level? How about
at python-level, if using a python port. Or does b2 itself (bjam) need
to be modified (I really should hope not!)...

I think I'm going back to think a bit more... If anyone who knows more
about b2 internals could give a hint as to whether this is even
possible...?

Thanks for the blog-links, Mateusz. I hadn't read those before; it's
always illuminating to see how others tackle a project.

Cheers!
 /Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPBkHgAAoJEKd8gmwzkHPJJB0IAI06Cu5vKn9uyuIN4I7GvO9P
RCPM2g/oXogEtn0tiWq59S4/8mDup9jXgLR9zpNZYXokUCblGUyTAX5twLyOLFl0
ueAmybNGPMwGgNVGI+NZgeU7lB4N6mMF0aqMabcQxTJDRRfH67Il4z1aTY0z7l1p
laGxSgnmEqzXSRPYWrxX4TlwB71WpStJ9N+VDHzRXg6BKS7odS6GVUaUgp4adhfB
+qTjUwv1g+GVMcHIWrquOBnjKh/rYkCTXRUDYXxkv/rdlAANVkDp1Vt/OgdRYqyq
akZJfKZEGHk8wZLEwuJD7PXMwSXkVe4ixtpGoj27cC3RmdLTmnegPdrccAfAzTY=
=opz5
-----END PGP SIGNATURE-----