Boost logo

Boost :

Subject: Re: [boost] [Modularization] A new approach to header modularization
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-05-29 03:36:59


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.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk