Boost logo

Boost :

Subject: Re: [boost] Interface for configuring third-party dependencies
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2010-10-23 11:03:51

On 23/10/10 13:22, Vladimir Prus wrote:
> Mateusz Loskot wrote:
>> On 20/10/10 09:13, Vladimir Prus wrote:
>>> Rene Rivera wrote:
>>>> The problem I see with that is that those will collide with my
>>>> extensions for building from source. And IIRC there are some Boost libs
>>>> with external dependencies that allow sources already (which builds the
>>>> library). More concretely.. I can't have both this prebuilt declaration,
>>>> and mine for zlib:
>>>> using zlib : 1.2.3 : $(ROOT)/sdk/zlib ;
>>> Well, you can't have exact same declaration, but it's possible to have this:
>>> using zlib : source $(ROOT)/sdk/zlib ;
>> Would it be possible to be able to determine version
>> and compare against min version required?
>>> Actually, it's probably reasonable to ask whether we want to support building
>>> from source for all external libraries, or for select ones, and if the latter,
>>> how do we decide? Supporting build from source for all libraries might easily
>>> become troublesome -- especially, if those libraries are being actively developed.
>> IMHO, building from source is not required.
>> There is usually no problem with building binaries if source available,
>> So, once installed, they could be specified to use by Boost.Build.
>>>> I'm assuming you will have some utilities for specifying things like the
>>>> version number of libraries since it's important some times to build
>>>> code against specific versions. Right?
>> Ah, so I have repeated this question above.
>>> That's a good question. I did not had it in my original plan. The primary
>>> problem I see is that a project might specify a certain version, while
>>> user-config.jam might not specify any, and:
>>> - requiring that user always specify version, especially for system libraries,
>>> is annoying
>>> - detecting the version automatically might be tricky.
>>> What do you suggest?
>> Mmy experiences suggest there are usually two
>> ways to determine version:
>> 1. Scan public header for preprocessor definition specifying version
>> 2. Call utility config program, like pg_config --version
>> If it would be possible to have these two schemes provided,
>> I think it should be well enough.
> I suppose this can work; however the first method requires that you actually
> find and open the header file. Which means that either:
> - Build system has to replicate path search logic of all compilers,
> - It's possible to ask the compiler where the header was found
> - Build system ignores any path search compiler might do, locates the
> headers/libraries on its own, and the forces the compiler to use them.
> Neither option is particularly attractive :-(

Volodya, I think you're right.
I'm out of idea what could be best solution.

Best regards,

Mateusz Loskot,
Charter Member of OSGeo,
Member of ACCU,

Boost list run by bdawes at, gregod at, cpdaniel at, john at