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 11:21:29

On 4/27/2011 10:18 AM, Vladimir Prus wrote:
> 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.

That is good news.

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

I understand that but at least Boost libraries can use this mechanism. 
Also it does seem as if 3rd party code using Boost Build should also 
work using this mechanism.