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