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

Subject: Re: [boost] [Modularization] A new approach to header modularization
From: Darryl Green (darryl.green_at_[hidden])
Date: 2009-05-30 03:44:30

On Fri, 2009-05-29 at 09:28 +0200, joaquin_at_[hidden] wrote:

> > - Code that must be there, e.g. templates
> >
> > - Performance reasons: 1) inlining functions and 2) not using pimpl in
> > code that is provably critical (the price is greater physical
> > coupling.)
> >   
> 
> These are points for a lib developer to evaluate, not the Boost user. 
> Remember we were
> talking of reasons why users prefer header-only.
> 
> Again, I've listed here my personal reasons (as a user). I think it 
> could be instructive to
> try to gather more insight as to why our users prefer header-only libs, 
> putting aside
> our own arguments as Boost authors.
> 

Well - here is input from one boost user.

I think single issue yes/no vote referendums produce some remarkably
silly answers, as do poorly selected sets of questions in surveys. I
could easily reply to a survey like this:

Do you want header only libs (no need to "build" boost)? yes

Do you want shorter builds? Yes

Do you want to be able to use "system" or otherwise separately
built/installed shared libraries rather than deploying libraries with
each product etc? Yes

Do you want to deal with the versioning and compatibility problems that
can sometimes arise with shared libraries? No

etc...

The above noisy results are a result of asking questions that have too
much to do with implementation. I don't care how the thing works so long
as it works well and is easy to use. I suspect that goes for most users.

To me easy to use means (things irrelevant to this thread elided):

easy to build

easy to deploy

If you expect users to answer *how* to do those things I think you are
giving users to much credit and/or trying to pass the buck on a hard
problem :-)

Now, if you avoid the need to build, you can't get easier than that - so
header only it is - right?

And if you don't need to deploy anything but the users own code - then
can't get easier tan that - done!

Header only is the winner!

As far as it goes, I think that is actually a pretty accurate answer. 

However, the problem is that I also want my projects to build in a
reasonable time, I don't want, when I build a whole suite of projects
all using a common library, to have to build a common library N times
once per project).

Surely it is clear that the header only approach ultimately does not
scale?

Surely it is also clear that shared lib compatibility, versioning etc is
a problem that can and has been solved?

My biggest build and deployment problems have nothing to do with boost.
Boost Build's uniqueness is not (now that the out of the box defaults
are good and the basic knobs to twiddle are better documented) a
significant impediment for basic use in my opinion at least.

Its unfortunate that so much work has had to be done (and a big thanks
to those responsible) to make Boost object code libraries easily
(relatively) usable and deployable on a very common platform that makes
these things remarkably hard. Please don't give up now!

Darryl.