Boost logo

Boost-Build :

Subject: Re: [Boost-build] [build] Compiler requirement for a header only library
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2011-04-27 10:18:55

Edward Diener wrote:

> On 4/26/2011 8:35 PM, Ian Emmons wrote:
>> On Apr 26, 2011, at 7:25 PM, Edward Diener wrote:
>>> On 4/26/2011 6:40 PM, Matthew Chambers wrote:
>>>> On 4/26/2011 7:03 AM, Vladimir Prus wrote:
>>>>> On Tuesday, April 26, 2011 05:58:47 Dean Michael Berris wrote:
>>>>>> On Tue, Apr 26, 2011 at 8:25 AM, Edward
>>>>>> Diener<eldiener_at_[hidden]> wrote:
>>>>>>> I have a header only library, which needs a particular compiler
>>>>>>> requirement to be set when the library's header files are included.
>>>>>>> I do
>>>>>>> not want to have to change the jam file for every library which uses my
>>>>>>> library. Is there a way to do this with Boost Build so that any library
>>>>>>> which includes one of my library's header files has the particular
>>>>>>> option for the particular compiler set properly. I do know about
>>>>>>> conditional requirements in Boost Build but I do not understand how a
>>>>>>> particular jamfile in a header directory can enforce such an option for
>>>>>>> other libraries.
>>>>>> In your header-only lib you can check for the options used to compile
>>>>>> it -- if it's not there, use #error or #warning to let the user know
>>>>>> what's to be done.
>>>>>> I'm not sure if there's a way to do this in Boost.Build itself,
>>>>>> although it would be awesome if there was a way to do this.
>>>>> While Boost.Build can technically do this, there are two problems:
>>>>> - Each Boost library would have to explicitly list other Boost
>>>>> header-only libraries that it uses
>>>>> - Use code, which might not be using Boost.Build, won't take advantage
>>>>> of this.
>>>>> I don't know how to overcome those issues.
>>>> Pretty much by definition you can't enforce compiler parameters with a
>>>> build system when the object of the enforcement doesn't ever need to be
>>>> built! A header-only library never needs to be mentioned in a Jamfile
>>>> (i.e. even if user code DOES use Boost.Build it likely won't be
>>>> specifying it in Jamfiles).
>>> Certainly a header-only library is a library like any other library, even if it does not
>>> produce a shared or static library. Because of that it is also a dependency of other libraries
>>> which use the header-only library. Therefore, at least conceptually, there should be a way to
>>> say in a build system that when one uses, ie includes a header file, of a header-only library,
>>> certain usage requirements of the header-only library should be met which are reflected by
>>> changes to the compile flags of the library using the header-only library.
>>> Perhaps this can be done in Boost Build by specifying the header-only library as a dependency
>>> of other libraries which use the header-only library, in those other libraries' jamfiles. But I
>>> am not sure of the syntax for such a dependency in Boost Build if it exists.
>> In a sense you are correct, but Volodya's first point renders your observation moot. Because
>> *all* Boost header-only libraries are accessible through the same Boost.Build<include>
>> directive, there is no way to ensure a requirement is applied for a specific one of them. The
>> only way to make this work in a way that is not ridiculously error-prone would be for every
>> header-only library to exist in a separate include directory, so that you are forced to list
>> each header-only library that you use separately. That would require a significant
>> rearrangement of the Boost directory hierarchy.
> The Boost Build <include> directive can not solve the problem. But
> surely some other sort of dependency in Boost Build can be created which
> does, and by which a library says that it depends on the header files of
> another library, and then uses the other header-only library's
> requirements to compile.

Of course:


        alias any : : : : <define>WHATEVER ;


        lib whatever : ... /boost/any//any ;

However, again:

1. There's no usable mechanism to make sure these dependencies are spelled out.
Everything works right now, even though libs/any/build/Jamfile does not even

2. It won't help for third party code including Boost headers -- which seems to
be a showstopper to me.

- Volodya

Vladimir Prus
Mentor Graphics
+7 (812) 677-68-40

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at