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

Subject: Re: [boost] Interface for configuring third-party dependencies
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2010-10-23 08:22:37

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