1[/ 2 Boost.Config 3 4 Copyright (c) 2001 Beman Dawes 5 Copyright (c) 2001 Vesa Karvonen 6 Copyright (c) 2001 John Maddock 7 8 Distributed under the Boost Software License, Version 1.0. 9 (See accompanying file LICENSE_1_0.txt or copy at 10 http://www.boost.org/LICENSE_1_0.txt) 11] 12 13[section Rationale] 14 15The problem with many traditional "textbook" implementations of configuration 16headers (where all the configuration options are in a single "monolithic" 17header) is that they violate certain fundamental software engineering 18principles which would have the effect of making boost more fragile, more 19difficult to maintain and more difficult to use safely. You can find a 20description of the principles from the __PRINCIPLES_AND_PATTERNS_ARTICLE__. 21 22[section The problem] 23 24Consider a situation in which you are concurrently developing on multiple 25platforms. Then consider adding a new platform or changing the platform 26definitions of an existing platform. What happens? Everything, and this does 27literally mean everything, recompiles. Isn't it quite absurd that adding a 28new platform, which has absolutely nothing to do with previously existing 29platforms, means that all code on all existing platforms needs to be 30recompiled? 31 32Effectively, there is an imposed physical dependency between platforms that 33have nothing to do with each other. Essentially, the traditional solution 34employed by configuration headers does not conform to the Open-Closed 35Principle: 36 37[: [*"A module should be open for extension but closed for modification."]] 38 39Extending a traditional configuration header implies modifying existing code. 40 41Furthermore, consider the complexity and fragility of the platform detection 42code. What if a simple change breaks the detection on some minor platform? 43What if someone accidentally or on purpose (as a workaround for some other 44problem) defines some platform dependent macros that are used by the 45detection code? A traditional configuration header is one of the most 46volatile headers of the entire library, and more stable elements of 47Boost would depend on it. This violates the Stable Dependencies Principle: 48 49[: [*"Depend in the direction of stability."]] 50 51After even a minor change to a traditional configuration header on one minor 52platform, almost everything on every platform should be tested if we follow 53sound software engineering practice. 54 55Another important issue is that it is not always possible to submit changes 56to `<boost/config.hpp>`. Some boost users are currently working on platforms 57using tools and libraries that are under strict Non-Disclosure Agreements. 58In this situation it is impossible to submit changes to a traditional 59monolithic configuration header, instead some method by which the user 60can insert their own configuration code must be provided. 61 62[endsect] 63 64[section The solution] 65 66The approach taken by boost's configuration headers is to separate 67configuration into three orthogonal parts: the compiler, the standard 68library and the platform. Each compiler/standard library/platform gets 69its own mini-configuration header, so that changes to one compiler's 70configuration (for example) does not affect other compilers. In addition 71there are measures that can be taken both to omit the compiler/standard 72library/platform detection code (so that adding support to a new platform 73does not break dependencies), or to freeze the configuration completely; 74providing almost complete protection against dependency changes. 75 76[endsect] 77 78[endsect] 79 80 81