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

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:

libs/any/build/Jamfile:

        alias any : : : : <define>WHATEVER ;

libs/whatever/build/Jamfile:

        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
exist.

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
[phone]