OSDN Git Service

70fb023bd02fc987cf7c43da86f3476412908c56
[pf3gnuchains/gcc-fork.git] / libstdc++-v3 / doc / html / manual / appendix_porting.html
1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
3 <html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Appendix B.  Porting and Maintenance</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /><meta name="keywords" content="&#10;      ISO C++&#10;    , &#10;      library&#10;    " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt04.html" title="Part IV.  Appendices" /><link rel="prev" href="source_design_notes.html" title="Design Notes" /><link rel="next" href="internals.html" title="Porting to New Hardware or Operating Systems" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Appendix B. 
4   Porting and Maintenance
5   
6 </th></tr><tr><td width="20%" align="left"><a accesskey="p" href="source_design_notes.html">Prev</a> </td><th width="60%" align="center">Part IV. 
7   Appendices
8 </th><td width="20%" align="right"> <a accesskey="n" href="internals.html">Next</a></td></tr></table><hr /></div><div class="appendix" title="Appendix B.  Porting and Maintenance"><div class="titlepage"><div><div><h2 class="title"><a id="appendix.porting"></a>Appendix B. 
9   Porting and Maintenance
10   <a id="id559270" class="indexterm"></a>
11 </h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="appendix_porting.html#appendix.porting.build_hacking">Configure and Build Hacking</a></span></dt><dd><dl><dt><span class="sect2"><a href="appendix_porting.html#build_hacking.prereq">Prerequisites</a></span></dt><dt><span class="sect2"><a href="appendix_porting.html#build_hacking.map">Overview: What Comes from Where</a></span></dt><dt><span class="sect2"><a href="appendix_porting.html#build_hacking.scripts">Storing Information in non-AC files (like configure.host)</a></span></dt><dt><span class="sect2"><a href="appendix_porting.html#build_hacking.conventions">Coding and Commenting Conventions</a></span></dt><dt><span class="sect2"><a href="appendix_porting.html#build_hacking.acinclude">The acinclude.m4 layout</a></span></dt><dt><span class="sect2"><a href="appendix_porting.html#build_hacking.enable"><code class="constant">GLIBCXX_ENABLE</code>, the <code class="literal">--enable</code> maker</a></span></dt></dl></dd><dt><span class="sect1"><a href="internals.html">Porting to New Hardware or Operating Systems</a></span></dt><dd><dl><dt><span class="sect2"><a href="internals.html#internals.os">Operating System</a></span></dt><dt><span class="sect2"><a href="internals.html#internals.cpu">CPU</a></span></dt><dt><span class="sect2"><a href="internals.html#internals.char_types">Character Types</a></span></dt><dt><span class="sect2"><a href="internals.html#internals.thread_safety">Thread Safety</a></span></dt><dt><span class="sect2"><a href="internals.html#internals.numeric_limits">Numeric Limits</a></span></dt><dt><span class="sect2"><a href="internals.html#internals.libtool">Libtool</a></span></dt></dl></dd><dt><span class="sect1"><a href="test.html">Test</a></span></dt><dd><dl><dt><span class="sect2"><a href="test.html#test.organization">Organization</a></span></dt><dt><span class="sect2"><a href="test.html#test.run">Running the Testsuite</a></span></dt><dt><span class="sect2"><a href="test.html#test.new_tests">Writing a new test case</a></span></dt><dt><span class="sect2"><a href="test.html#test.harness">Test Harness and Utilities</a></span></dt><dt><span class="sect2"><a href="test.html#test.special">Special Topics</a></span></dt></dl></dd><dt><span class="sect1"><a href="abi.html">ABI Policy and Guidelines</a></span></dt><dd><dl><dt><span class="sect2"><a href="abi.html#abi.cxx_interface">The C++ Interface</a></span></dt><dt><span class="sect2"><a href="abi.html#abi.versioning">Versioning</a></span></dt><dt><span class="sect2"><a href="abi.html#abi.changes_allowed">Allowed Changes</a></span></dt><dt><span class="sect2"><a href="abi.html#abi.changes_no">Prohibited Changes</a></span></dt><dt><span class="sect2"><a href="abi.html#abi.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="abi.html#abi.testing">Testing</a></span></dt><dt><span class="sect2"><a href="abi.html#abi.issues">Outstanding Issues</a></span></dt></dl></dd><dt><span class="sect1"><a href="api.html">API Evolution and Deprecation History</a></span></dt><dd><dl><dt><span class="sect2"><a href="api.html#api.rel_300"><code class="constant">3.0</code></a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_310"><code class="constant">3.1</code></a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_320"><code class="constant">3.2</code></a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_330"><code class="constant">3.3</code></a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_340"><code class="constant">3.4</code></a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_400"><code class="constant">4.0</code></a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_410"><code class="constant">4.1</code></a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_420"><code class="constant">4.2</code></a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_430"><code class="constant">4.3</code></a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_440"><code class="constant">4.4</code></a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_450"><code class="constant">4.5</code></a></span></dt></dl></dd><dt><span class="sect1"><a href="backwards.html">Backwards Compatibility</a></span></dt><dd><dl><dt><span class="sect2"><a href="backwards.html#backwards.first">First</a></span></dt><dt><span class="sect2"><a href="backwards.html#backwards.second">Second</a></span></dt><dt><span class="sect2"><a href="backwards.html#backwards.third">Third</a></span></dt></dl></dd></dl></div><div class="sect1" title="Configure and Build Hacking"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="appendix.porting.build_hacking"></a>Configure and Build Hacking</h2></div></div></div><div class="sect2" title="Prerequisites"><div class="titlepage"><div><div><h3 class="title"><a id="build_hacking.prereq"></a>Prerequisites</h3></div></div></div><p>
12     As noted <a class="ulink" href="http://gcc.gnu.org/install/prerequisites.html" target="_top">previously</a>,
13     certain other tools are necessary for hacking on files that
14     control configure (<code class="code">configure.ac</code>,
15     <code class="code">acinclude.m4</code>) and make
16     (<code class="code">Makefile.am</code>). These additional tools
17     (<code class="code">automake</code>, and <code class="code">autoconf</code>) are further
18     described in detail in their respective manuals. All the libraries
19     in GCC try to stay in sync with each other in terms of versions of
20     the auto-tools used, so please try to play nicely with the
21     neighbors.
22   </p></div><div class="sect2" title="Overview: What Comes from Where"><div class="titlepage"><div><div><h3 class="title"><a id="build_hacking.map"></a>Overview: What Comes from Where</h3></div></div></div><pre class="screen">
23   <img src="../images/confdeps.png" alt="Dependency Graph Configure to Build Files" />
24   </pre><p>
25     Regenerate all generated files by using the command sequence
26     <code class="code">"autoreconf"</code> at the top level of the libstdc++ source
27     directory. The following will also work, but is much more complex:
28     <code class="code">"aclocal-1.11 &amp;&amp; autoconf-2.64 &amp;&amp;
29     autoheader-2.64 &amp;&amp; automake-1.11"</code> The version
30     numbers may be absent entirely or otherwise vary depending on
31     <a class="ulink" href="http://gcc.gnu.org/install/prerequisites.html" target="_top">the
32     current requirements</a> and your vendor's choice of
33     installation names.
34   </p></div><div class="sect2" title="Storing Information in non-AC files (like configure.host)"><div class="titlepage"><div><div><h3 class="title"><a id="build_hacking.scripts"></a>Storing Information in non-AC files (like configure.host)</h3></div></div></div><p>
35     Until that glorious day when we can use AC_TRY_LINK with a
36     cross-compiler, we have to hardcode the results of what the tests
37     would have shown if they could be run.  So we have an inflexible
38     mess like crossconfig.m4.
39   </p><p>
40     Wouldn't it be nice if we could store that information in files
41     like configure.host, which can be modified without needing to
42     regenerate anything, and can even be tweaked without really
43     knowing how the configury all works?  Perhaps break the pieces of
44     crossconfig.m4 out and place them in their appropriate
45     config/{cpu,os} directory.
46   </p><p>
47     Alas, writing macros like
48     "<code class="code">AC_DEFINE(HAVE_A_NICE_DAY)</code>" can only be done inside
49     files which are passed through autoconf.  Files which are pure
50     shell script can be source'd at configure time.  Files which
51     contain autoconf macros must be processed with autoconf.  We could
52     still try breaking the pieces out into "config/*/cross.m4" bits,
53     for instance, but then we would need arguments to aclocal/autoconf
54     to properly find them all when generating configure.  I would
55     discourage that.
56 </p></div><div class="sect2" title="Coding and Commenting Conventions"><div class="titlepage"><div><div><h3 class="title"><a id="build_hacking.conventions"></a>Coding and Commenting Conventions</h3></div></div></div><p>
57     Most comments should use {octothorpes, shibboleths, hash marks,
58     pound signs, whatever} rather than "dnl".  Nearly all comments in
59     configure.ac should.  Comments inside macros written in ancilliary
60     .m4 files should.  About the only comments which should
61     <span class="emphasis"><em>not</em></span> use #, but use dnl instead, are comments
62     <span class="emphasis"><em>outside</em></span> our own macros in the ancilliary
63     files.  The difference is that # comments show up in
64     <code class="code">configure</code> (which is most helpful for debugging),
65     while dnl'd lines just vanish.  Since the macros in ancilliary
66     files generate code which appears in odd places, their "outside"
67     comments tend to not be useful while reading
68     <code class="code">configure</code>.
69   </p><p>
70     Do not use any <code class="code">$target*</code> variables, such as
71     <code class="code">$target_alias</code>.  The single exception is in
72     configure.ac, for automake+dejagnu's sake.
73   </p></div><div class="sect2" title="The acinclude.m4 layout"><div class="titlepage"><div><div><h3 class="title"><a id="build_hacking.acinclude"></a>The acinclude.m4 layout</h3></div></div></div><p>
74     The nice thing about acinclude.m4/aclocal.m4 is that macros aren't
75     actually performed/called/expanded/whatever here, just loaded.  So
76     we can arrange the contents however we like.  As of this writing,
77     acinclude.m4 is arranged as follows:
78   </p><pre class="programlisting">
79     GLIBCXX_CHECK_HOST
80     GLIBCXX_TOPREL_CONFIGURE
81     GLIBCXX_CONFIGURE
82   </pre><p>
83     All the major variable "discovery" is done here.  CXX, multilibs,
84     etc.
85   </p><pre class="programlisting">
86     fragments included from elsewhere
87   </pre><p>
88     Right now, "fragments" == "the math/linkage bits".
89   </p><pre class="programlisting">
90     GLIBCXX_CHECK_COMPILER_FEATURES
91     GLIBCXX_CHECK_LINKER_FEATURES
92     GLIBCXX_CHECK_WCHAR_T_SUPPORT
93 </pre><p>
94   Next come extra compiler/linker feature tests.  Wide character
95   support was placed here because I couldn't think of another place
96   for it.  It will probably get broken apart like the math tests,
97   because we're still disabling wchars on systems which could actually
98   support them.
99 </p><pre class="programlisting">
100     GLIBCXX_CHECK_SETRLIMIT_ancilliary
101     GLIBCXX_CHECK_SETRLIMIT
102     GLIBCXX_CHECK_S_ISREG_OR_S_IFREG
103     GLIBCXX_CHECK_POLL
104     GLIBCXX_CHECK_WRITEV
105
106     GLIBCXX_CONFIGURE_TESTSUITE
107 </pre><p>
108   Feature tests which only get used in one place.  Here, things used
109   only in the testsuite, plus a couple bits used in the guts of I/O.
110 </p><pre class="programlisting">
111     GLIBCXX_EXPORT_INCLUDES
112     GLIBCXX_EXPORT_FLAGS
113     GLIBCXX_EXPORT_INSTALL_INFO
114 </pre><p>
115   Installation variables, multilibs, working with the rest of the
116   compiler.  Many of the critical variables used in the makefiles are
117   set here.
118 </p><pre class="programlisting">
119     GLIBGCC_ENABLE
120     GLIBCXX_ENABLE_C99
121     GLIBCXX_ENABLE_CHEADERS
122     GLIBCXX_ENABLE_CLOCALE
123     GLIBCXX_ENABLE_CONCEPT_CHECKS
124     GLIBCXX_ENABLE_CSTDIO
125     GLIBCXX_ENABLE_CXX_FLAGS
126     GLIBCXX_ENABLE_C_MBCHAR
127     GLIBCXX_ENABLE_DEBUG
128     GLIBCXX_ENABLE_DEBUG_FLAGS
129     GLIBCXX_ENABLE_LONG_LONG
130     GLIBCXX_ENABLE_PCH
131     GLIBCXX_ENABLE_SJLJ_EXCEPTIONS
132     GLIBCXX_ENABLE_SYMVERS
133     GLIBCXX_ENABLE_THREADS
134 </pre><p>
135   All the features which can be controlled with enable/disable
136   configure options.  Note how they're alphabetized now?  Keep them
137   like that.  :-)
138 </p><pre class="programlisting">
139     AC_LC_MESSAGES
140     libtool bits
141 </pre><p>
142   Things which we don't seem to use directly, but just has to be
143   present otherwise stuff magically goes wonky.
144 </p></div><div class="sect2" title="GLIBCXX_ENABLE, the --enable maker"><div class="titlepage"><div><div><h3 class="title"><a id="build_hacking.enable"></a><code class="constant">GLIBCXX_ENABLE</code>, the <code class="literal">--enable</code> maker</h3></div></div></div><p>
145     All the GLIBCXX_ENABLE_FOO macros use a common helper,
146     GLIBCXX_ENABLE.  (You don't have to use it, but it's easy.)  The
147     helper does two things for us:
148   </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
149      Builds the call to the AC_ARG_ENABLE macro, with --help text
150      properly quoted and aligned.  (Death to changequote!)
151    </p></li><li class="listitem"><p>
152      Checks the result against a list of allowed possibilities, and
153      signals a fatal error if there's no match.  This means that the
154      rest of the GLIBCXX_ENABLE_FOO macro doesn't need to test for
155      strange arguments, nor do we need to protect against
156      empty/whitespace strings with the <code class="code">"x$foo" = "xbar"</code>
157      idiom.
158    </p></li></ol></div><p>Doing these things correctly takes some extra autoconf/autom4te code,
159    which made our macros nearly illegible.  So all the ugliness is factored
160    out into this one helper macro.
161 </p><p>Many of the macros take an argument, passed from when they are expanded
162    in configure.ac.  The argument controls the default value of the
163    enable/disable switch.  Previously, the arguments themselves had defaults.
164    Now they don't, because that's extra complexity with zero gain for us.
165 </p><p>There are three "overloaded signatures".  When reading the descriptions
166    below, keep in mind that the brackets are autoconf's quotation characters,
167    and that they will be stripped.  Examples of just about everything occur
168    in acinclude.m4, if you want to look.
169 </p><pre class="programlisting">
170     GLIBCXX_ENABLE (FEATURE, DEFAULT, HELP-ARG, HELP-STRING)
171     GLIBCXX_ENABLE (FEATURE, DEFAULT, HELP-ARG, HELP-STRING, permit a|b|c)
172     GLIBCXX_ENABLE (FEATURE, DEFAULT, HELP-ARG, HELP-STRING, SHELL-CODE-HANDLER)
173 </pre><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
174      FEATURE is the string that follows --enable.  The results of the
175      test (such as it is) will be in the variable $enable_FEATURE,
176      where FEATURE has been squashed.  Example:
177      <code class="code">[extra-foo]</code>, controlled by the --enable-extra-foo
178      option and stored in $enable_extra_foo.
179    </p></li><li class="listitem"><p>
180      DEFAULT is the value to store in $enable_FEATURE if the user does
181      not pass --enable/--disable.  It should be one of the permitted
182      values passed later.  Examples: <code class="code">[yes]</code>, or
183      <code class="code">[bar]</code>, or <code class="code">[$1]</code> (which passes the
184      argument given to the GLIBCXX_ENABLE_FOO macro as the
185      default).
186    </p><p>
187      For cases where we need to probe for particular models of things,
188      it is useful to have an undocumented "auto" value here (see
189      GLIBCXX_ENABLE_CLOCALE for an example).
190    </p></li><li class="listitem"><p>
191      HELP-ARG is any text to append to the option string itself in the
192      --help output.  Examples: <code class="code">[]</code> (i.e., an empty string,
193      which appends nothing), <code class="code">[=BAR]</code>, which produces
194      <code class="code">--enable-extra-foo=BAR</code>, and
195      <code class="code">[@&lt;:@=BAR@:&gt;@]</code>, which produces
196      <code class="code">--enable-extra-foo[=BAR]</code>.  See the difference?  See
197      what it implies to the user?
198    </p><p>
199      If you're wondering what that line noise in the last example was,
200      that's how you embed autoconf special characters in output text.
201      They're called <a class="ulink" href="http://www.gnu.org/software/autoconf/manual/autoconf.html#Quadrigraphs" target="_top"><span class="emphasis"><em>quadrigraphs</em></span></a>
202      and you should use them whenever necessary.
203  </p></li><li class="listitem"><p>HELP-STRING is what you think it is.  Do not include the
204    "default" text like we used to do; it will be done for you by
205    GLIBCXX_ENABLE.  By convention, these are not full English
206    sentences.  Example: [turn on extra foo]
207    </p></li></ul></div><p>
208   With no other arguments, only the standard autoconf patterns are
209   allowed: "<code class="code">--{enable,disable}-foo[={yes,no}]</code>" The
210   $enable_FEATURE variable is guaranteed to equal either "yes" or "no"
211   after the macro.  If the user tries to pass something else, an
212   explanatory error message will be given, and configure will halt.
213 </p><p>
214   The second signature takes a fifth argument, "<code class="code">[permit
215   a | b | c | ...]</code>"
216   This allows <span class="emphasis"><em>a</em></span> or <span class="emphasis"><em>b</em></span> or
217   ... after the equals sign in the option, and $enable_FEATURE is
218   guaranteed to equal one of them after the macro.  Note that if you
219   want to allow plain --enable/--disable with no "=whatever", you must
220   include "yes" and "no" in the list of permitted values.  Also note
221   that whatever you passed as DEFAULT must be in the list.  If the
222   user tries to pass something not on the list, a semi-explanatory
223   error message will be given, and configure will halt.  Example:
224   <code class="code">[permit generic|gnu|ieee_1003.1-2001|yes|no|auto]</code>
225 </p><p>
226   The third signature takes a fifth argument.  It is arbitrary shell
227   code to execute if the user actually passes the enable/disable
228   option.  (If the user does not, the default is used.  Duh.)  No
229   argument checking at all is done in this signature.  See
230   GLIBCXX_ENABLE_CXX_FLAGS for an example of handling, and an error
231   message.
232 </p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="source_design_notes.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt04.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="internals.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Design Notes </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Porting to New Hardware or Operating Systems</td></tr></table></div></body></html>