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