]>
Commit | Line | Data |
---|---|---|
7c673cae FG |
1 | <html> |
2 | <head> | |
3 | <meta http-equiv="Content-Type" content="text/html; charset=US-ASCII"> | |
4 | <title>Rationale</title> | |
5 | <link rel="stylesheet" href="../../../../../doc/src/boostbook.css" type="text/css"> | |
6 | <meta name="generator" content="DocBook XSL Stylesheets V1.77.1"> | |
7 | <link rel="home" href="../index.html" title="Boost.Config"> | |
8 | <link rel="up" href="../index.html" title="Boost.Config"> | |
9 | <link rel="prev" href="guidelines_for_boost_authors.html" title="Guidelines for Boost Authors"> | |
10 | <link rel="next" href="acknowledgements.html" title="Acknowledgements"> | |
11 | </head> | |
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> | |
13 | <table cellpadding="2" width="100%"><tr> | |
14 | <td valign="top"><img alt="Boost C++ Libraries" width="277" height="86" src="../../../../../boost.png"></td> | |
15 | <td align="center"><a href="../../../../../index.html">Home</a></td> | |
16 | <td align="center"><a href="../../../../../libs/libraries.htm">Libraries</a></td> | |
17 | <td align="center"><a href="http://www.boost.org/users/people.html">People</a></td> | |
18 | <td align="center"><a href="http://www.boost.org/users/faq.html">FAQ</a></td> | |
19 | <td align="center"><a href="../../../../../more/index.htm">More</a></td> | |
20 | </tr></table> | |
21 | <hr> | |
22 | <div class="spirit-nav"> | |
23 | <a accesskey="p" href="guidelines_for_boost_authors.html"><img src="../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../index.html"><img src="../../../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../../../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="acknowledgements.html"><img src="../../../../../doc/src/images/next.png" alt="Next"></a> | |
24 | </div> | |
25 | <div class="section"> | |
26 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | |
27 | <a name="boost_config.rationale"></a><a class="link" href="rationale.html" title="Rationale">Rationale</a> | |
28 | </h2></div></div></div> | |
29 | <div class="toc"><dl> | |
30 | <dt><span class="section"><a href="rationale.html#boost_config.rationale.the_problem">The problem</a></span></dt> | |
31 | <dt><span class="section"><a href="rationale.html#boost_config.rationale.the_solution">The solution</a></span></dt> | |
32 | </dl></div> | |
33 | <p> | |
34 | The problem with many traditional "textbook" implementations of configuration | |
35 | headers (where all the configuration options are in a single "monolithic" | |
36 | header) is that they violate certain fundamental software engineering principles | |
37 | which would have the effect of making boost more fragile, more difficult to | |
38 | maintain and more difficult to use safely. You can find a description of the | |
39 | principles from the <a href="http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf" target="_top">following | |
40 | article</a>. | |
41 | </p> | |
42 | <div class="section"> | |
43 | <div class="titlepage"><div><div><h3 class="title"> | |
44 | <a name="boost_config.rationale.the_problem"></a><a class="link" href="rationale.html#boost_config.rationale.the_problem" title="The problem">The problem</a> | |
45 | </h3></div></div></div> | |
46 | <p> | |
47 | Consider a situation in which you are concurrently developing on multiple | |
48 | platforms. Then consider adding a new platform or changing the platform definitions | |
49 | of an existing platform. What happens? Everything, and this does literally | |
50 | mean everything, recompiles. Isn't it quite absurd that adding a new platform, | |
51 | which has absolutely nothing to do with previously existing platforms, means | |
52 | that all code on all existing platforms needs to be recompiled? | |
53 | </p> | |
54 | <p> | |
55 | Effectively, there is an imposed physical dependency between platforms that | |
56 | have nothing to do with each other. Essentially, the traditional solution | |
57 | employed by configuration headers does not conform to the Open-Closed Principle: | |
58 | </p> | |
59 | <div class="blockquote"><blockquote class="blockquote"><p> | |
60 | <span class="bold"><strong>"A module should be open for extension but closed | |
61 | for modification."</strong></span> | |
62 | </p></blockquote></div> | |
63 | <p> | |
64 | Extending a traditional configuration header implies modifying existing code. | |
65 | </p> | |
66 | <p> | |
67 | Furthermore, consider the complexity and fragility of the platform detection | |
68 | code. What if a simple change breaks the detection on some minor platform? | |
69 | What if someone accidentally or on purpose (as a workaround for some other | |
70 | problem) defines some platform dependent macros that are used by the detection | |
71 | code? A traditional configuration header is one of the most volatile headers | |
72 | of the entire library, and more stable elements of Boost would depend on | |
73 | it. This violates the Stable Dependencies Principle: | |
74 | </p> | |
75 | <div class="blockquote"><blockquote class="blockquote"><p> | |
76 | <span class="bold"><strong>"Depend in the direction of stability."</strong></span> | |
77 | </p></blockquote></div> | |
78 | <p> | |
79 | After even a minor change to a traditional configuration header on one minor | |
80 | platform, almost everything on every platform should be tested if we follow | |
81 | sound software engineering practice. | |
82 | </p> | |
83 | <p> | |
84 | Another important issue is that it is not always possible to submit changes | |
85 | to <code class="computeroutput"><span class="special"><</span><span class="identifier">boost</span><span class="special">/</span><span class="identifier">config</span><span class="special">.</span><span class="identifier">hpp</span><span class="special">></span></code>. | |
86 | Some boost users are currently working on platforms using tools and libraries | |
87 | that are under strict Non-Disclosure Agreements. In this situation it is | |
88 | impossible to submit changes to a traditional monolithic configuration header, | |
89 | instead some method by which the user can insert their own configuration | |
90 | code must be provided. | |
91 | </p> | |
92 | </div> | |
93 | <div class="section"> | |
94 | <div class="titlepage"><div><div><h3 class="title"> | |
95 | <a name="boost_config.rationale.the_solution"></a><a class="link" href="rationale.html#boost_config.rationale.the_solution" title="The solution">The solution</a> | |
96 | </h3></div></div></div> | |
97 | <p> | |
98 | The approach taken by boost's configuration headers is to separate configuration | |
99 | into three orthogonal parts: the compiler, the standard library and the platform. | |
100 | Each compiler/standard library/platform gets its own mini-configuration header, | |
101 | so that changes to one compiler's configuration (for example) does not affect | |
102 | other compilers. In addition there are measures that can be taken both to | |
103 | omit the compiler/standard library/platform detection code (so that adding | |
104 | support to a new platform does not break dependencies), or to freeze the | |
105 | configuration completely; providing almost complete protection against dependency | |
106 | changes. | |
107 | </p> | |
108 | </div> | |
109 | </div> | |
110 | <table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr> | |
111 | <td align="left"></td> | |
112 | <td align="right"><div class="copyright-footer">Copyright © 2001-2007 Beman Dawes, Vesa Karvonen, John | |
113 | Maddock<p> | |
114 | Distributed under the Boost Software License, Version 1.0. (See accompanying | |
115 | file LICENSE_1_0.txt or copy at <a href="http://www.boost.org/LICENSE_1_0.txt" target="_top">http://www.boost.org/LICENSE_1_0.txt</a>) | |
116 | </p> | |
117 | </div></td> | |
118 | </tr></table> | |
119 | <hr> | |
120 | <div class="spirit-nav"> | |
121 | <a accesskey="p" href="guidelines_for_boost_authors.html"><img src="../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../index.html"><img src="../../../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../../../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="acknowledgements.html"><img src="../../../../../doc/src/images/next.png" alt="Next"></a> | |
122 | </div> | |
123 | </body> | |
124 | </html> |