Re: [boost] [system][chrono] header-only libs

Subject: Re: [boost] [system][chrono] header-only libs
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-06 16:41:41

On Fri, Jan 7, 2011 at 5:32 AM, Stewart, Robert <Robert.Stewart_at_[hidden]> wrote:
> Dean Michael Berris wrote:
>> On Fri, Jan 7, 2011 at 4:37 AM, Stewart, Robert
>> <Robert.Stewart_at_[hidden]> wrote:
>>
>> > Given that most Boost libraries are header only, it seems
>> > as if those that provide an option to deviate from that norm,
>> > should do so explicitly. Â Thus, the name and behavior should
>> > be reversed: Â BOOST_XXXXX_AS_LIBRARY.
>>
>> Right, but unfortunately for Boost.System's case, the default usage
>> has been as a library, therefore an option should be explicitly turned
>> on to deviate from its default distribution/usage scenario.
>
> I did consider that, and my suggestion would be an implicit change for Boost.System users, but the question is whether there's any real problem that would make the shift troublesome for most users.
>

At least in my case, having a library that depends on Boost.System, it
does break things. Consider the case when the user blindly just
updates Boost, rebuilds the binaries, and starts seeing linker errors
when suddenly Boost.System has just become header-only by default.
This also messes up the packaging for Boost on Linux distributions
too.

> Regardless of the Boost.System decision, all Boost libraries with such a build option should use the same approach. Â It should not be the case that some libraries require active changes to build as a library while others require active steps to build header-only.
>
> Since Boost.System is the only library in that situation -- at the moment, anyway -- Beman can choose as he sees fit, but defaulting to the expected norm for Boost libraries is ideal.
>

I don't know about "should all use the same approach". I don't see why
complimentary options would be a problem. More specifically, those
that have been by default header-only to suddenly have a
non-header-only option should make that an option because it is the
deviation from the status quo; and those that are not header-only to
have that non-header-only option available. I don't see why offering
BOOST_XXX_HEADER_ONLY for non-header-only libs and
BOOST_XXX_AS_LIBRARY for header-only libs would be a problem.

Am I missing something?

-- 
Dean Michael Berris
about.me/deanberris