Re: [Boost-build] [build] Compiler requirement for a header only library

Subject: Re: [Boost-build] [build] Compiler requirement for a header only library
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-04-27 10:09:41

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.