Re: [boost] Boost Modularization: did we get it right?

Subject: Re: [boost] Boost Modularization: did we get it right?
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2012-05-21 18:51:45

On 05/21/2012 06:54 PM, Dave Abrahams wrote:
> on Thu May 17 2012, Bjørn Roald<bjorn-AT-4roald.org>  wrote:
>
>> On 05/12/2012 04:36 AM, Dave Abrahams wrote:
>>> If I were going to invest in this I'd use forwarding headers and a link
>>> rewriter for the HTML.
>> Agree. At least for headers.
>>
>> Based on some experience, I think the really annoying thing is to have
>> your editor or IDE during debugging or from log files or build output,
>> take you to the trouble spot in your code.  You see the problem, but
>> do not realize you are in the *wrong* place.  So you fix it - you
>> think.
>>
>> So what happens then.  If you are lucky, the build fails on next
>> compile as it realizes the content of the derived file, the copy, has
>> changed.  But most build tools may not, as the the derived file has
>> been edited.  So it is more likely you discover a lot of your changes
>> are overwritten next time you do a rebuild all or make clean.
>>
>> Making the copies read-only may help a bit and remind the anyyed
>> earlier of the issue, but I think forwarding headers is better.  If
>> the indirection annoys you in other ways, use a more appropriate file
>> system.
>>
>>> But I advise not investing too much in the
>>> options here, as this whole monolithic arrangement should be
>>> short-lived.
>> I am curious why you consider installing headers for build part of a
>> monolitic arrangement.
> I don't.  I consider *forwarding* headers part of a monolithic
> arrangement.

I assume you consider forwarding headers with symbolic, and hard links 
part of a monolithic arrangement as well, not only generated files with 
a single #include line to where the real file is.

> When you build modularized Boost using CMake no such
> headers are needed.
>

Is it modularized Boost, or CMake that solves that?

I suspect you refer to some mechanism deploying boost source and 
possibly binaries   into the development environment before you invoke 
CMake to generate your build system.  So if that is what you are 
thinking, having an installer arrange the headers the way you need them 
for builds is in your opinion not monolithic.  But having the build 
system do the same thing is.  Sorry, I don't agree.

If you wish to reduce the number of directories in your projects include 
paths, you need somehow to arrange headers in a common structure.  You 
could do without such a common header file structure with any sensible 
build system, Boost.Build as well I would think.  But such solutions has 
its own issues with scaling to a potentially high number of include paths.

Providing a mechanism to arrange a common header file structure out of 
selected parts is not monolithic in my view.  What is monolithic with 
the current arrangement, is the way the pieces of boost source is 
deployed, as one big hunk.

I am eager to see how the proposals for using 0Install works out and 
what change management work flows this will support.  I am a bit 
concerned with how well it would play with work flows and Git, but I am 
probably not seeing the whole picture. However I see no reason why 
making boost modularized need to be tied to replacing Boost.Build.

Git.Submodules + Boost.Build based solution has a very simple tool 
chain, potential to be modularized but may lack some desired features 
with managing multitudes of package interrelationships.

Git + 0Install + Boost.Build based solution is a more complex tool chain 
and possibly more complex process too manage it, but it may add flexible 
dependency management between packages, something Git.Submodule most 
likely lacks.  So this clearly can be modularized on the expense of some 
tool chain complexity.

Git + 0Install + CMake + make/MSVC/... based solution is even more 
complex tool chain, but some will argue that this adds the only correct 
way to build these days.  It does however not add anything to modularize 
boost over the alternatives above.

--
Bjørn