Subject: Re: [Boost-build] Locating libraries
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2012-01-06 05:50:44
On 6 January 2012 00:35, Brian Ravnsgaard Riis <brian_at_[hidden]> wrote:
> On 05-01-2012 16:27, Mateusz Loskot wrote:
>> 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:
>> 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
It is a bit similar to maintaining Find*.cmake modules, but requires
more detailed workout, indeed.
> But what about pre-built libs?
I'm sure Volodya has already solve it at least conceptually ;-)
It is only due his time constraints we haven't seen it implemented.
(I'm amazed how I am so unable to grasp the Boost.Build, it is easier for
me to learn C++ or any new langauge than the Jam'fu.
Quite unfortunate for myself.)
> 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
Yes, it could.
> 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.
Indeed, the difference is clear.
> Just thinking out loud here...
It is interesting reading, but I'm hardly able to comment it
with anything relevant or new.
-- Mateusz Loskot, http://mateusz.loskot.net
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk