Re: [boost] [Modularization] A new approach to header modularization

Subject: Re: [boost] [Modularization] A new approach to header modularization
From: joaquin_at_[hidden]
Date: 2009-05-29 02:39:22

Emil Dotchevski escribió:
> On Thu, May 28, 2009 at 11:15 PM, Joaquin M Lopez Munoz <joaquin_at_[hidden]> wrote:
>   
>> Emil Dotchevski <emildotchevski <at> gmail.com> writes:
>>
>>     
>>> On Thu, May 28, 2009 at 10:50 PM,  <joaquin <at> tid.es> wrote:
>>>       
>>>> Why there's pressure from users to keep Boost libs header-only? Boost is
>>>> for the users, so their reasons should be given proper weight.
>>>>         
>>> One can not create good design (in general, not just in software) by
>>> asking the users what would they like.
>>>       
>> I'd rather not go into discussing such far-reaching issues
>> as design theory, but you haven't asked my question:
>> What are the particular reasons why users demand header-only
>> libraries?
>>     
>
> Probably different users have different reasons. One reason might be
> that it makes Boost easier to install initially. What's your point?
>   

My point is that if there's pressure from users to have header-only libs (as
you and also I recognize) I think the least we can do is try to 
understand and
analyze these reasons to see their merit. If pressure were the other
way around (i.e. users demanding that code be moved out of .hpps as
much as possible) we wouldn't be having this sort of discussions.

As a user, I can describe *my* reasons to favor header-only libs:

1. The whole bjam-driven building process is nontrivial and time and
space consuming.
2. If autolinking is not available, picking up the right lib variant is not
trivial.
3. Bulding libs selectively is not as easy as it might seem, due to the
fact that interlib dependencies might force you to build libB when using
libA, and you don't know in advance.
4. I'm not concerned about ABI issues given that, to start with,
no ABI compatibility guarantees are provided across Boost versions.

This is not to say that I'd like *every* lib to be header-only; but
I'd say the benefits of moving to a link-based lib should be balanced
against points 1-4.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo