Re: [boost] Interface for configuring third-party dependencies

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, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org