|
Boost : |
Subject: Re: [boost] [Modularization] A new approach to header modularization
From: Christopher Jefferson (chris_at_[hidden])
Date: 2009-05-29 03:49:07
On 29 May 2009, at 08:36, Emil Dotchevski wrote:
> On Fri, May 29, 2009 at 12:28 AM, <joaquin_at_[hidden]> wrote:
>> Emil Dotchevski escribió:
>>>
>>> On Thu, May 28, 2009 at 11:39 PM, <joaquin_at_[hidden]> wrote:
>>>
>>>>
>>>> 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.
>>>>
>>>
>>> [...]
>>>
>>>
>>>>
>>>> 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.
>>>>
>>>
>>> Assume for a moment that 1-3 were solved at the build system level.
>>>
>>
>> Assuming 1-3 were solved is tantamount to assuming that building
>> libs is as
>> painless as not having to build them. Under these conditions of
>> course I'd
>> have no reason to prefer one solution to the other.
>
> One way to make building libs as painless as not having to build them
> is to use Boost Build itself to build your programs. It makes the
> presence of cpps/libs an implementation detail. In my own code
> repository, I have many libs and many cpp files and many header-only
> libs and I don't keep track which is which -- Boost Build figures it
> out for me.
Expecting people to change their build system just for one library
doesn't seem sensible! What if some other library decided we should
use their specialised build system? Also, I don't believe boost build
supports all the features of cmake I'm currently using anyway.
Chris
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk