| 1 | <html> |
|---|
| 2 | <head> |
|---|
| 3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> |
|---|
| 4 | <title>Toolset modules</title> |
|---|
| 5 | <link rel="stylesheet" href="../../boostbook.css" type="text/css"> |
|---|
| 6 | <meta name="generator" content="DocBook XSL Stylesheets V1.69.1"> |
|---|
| 7 | <style type="text/css"> |
|---|
| 8 | body { background-image: url('http://docbook.sourceforge.net/release/images/draft.png'); |
|---|
| 9 | background-repeat: no-repeat; |
|---|
| 10 | background-position: top left; |
|---|
| 11 | /* The following properties make the watermark "fixed" on the page. */ |
|---|
| 12 | /* I think that's just a bit too distracting for the reader... */ |
|---|
| 13 | /* background-attachment: fixed; */ |
|---|
| 14 | /* background-position: center center; */ |
|---|
| 15 | }</style> |
|---|
| 16 | <link rel="start" href="../../index.html" title="The Boost C++ Libraries"> |
|---|
| 17 | <link rel="up" href="../extender.html" title="Chapter 25. Extender Manual"> |
|---|
| 18 | <link rel="prev" href="rules.html" title="Main target rules"> |
|---|
| 19 | <link rel="next" href="../reference.html" title="Chapter 26. Detailed reference"> |
|---|
| 20 | </head> |
|---|
| 21 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> |
|---|
| 22 | <table cellpadding="2" width="100%"> |
|---|
| 23 | <td valign="top"><img alt="boost.png (6897 bytes)" width="277" height="86" src="../../../../boost.png"></td> |
|---|
| 24 | <td align="center"><a href="../../../../index.htm">Home</a></td> |
|---|
| 25 | <td align="center"><a href="../../../../libs/libraries.htm">Libraries</a></td> |
|---|
| 26 | <td align="center"><a href="../../../../people/people.htm">People</a></td> |
|---|
| 27 | <td align="center"><a href="../../../../more/faq.htm">FAQ</a></td> |
|---|
| 28 | <td align="center"><a href="../../../../more/index.htm">More</a></td> |
|---|
| 29 | </table> |
|---|
| 30 | <hr> |
|---|
| 31 | <div class="spirit-nav"> |
|---|
| 32 | <a accesskey="p" href="rules.html"><img src="../../images/prev.png" alt="Prev"></a><a accesskey="u" href="../extender.html"><img src="../../images/up.png" alt="Up"></a><a accesskey="h" href="../../index.html"><img src="../../images/home.png" alt="Home"></a><a accesskey="n" href="../reference.html"><img src="../../images/next.png" alt="Next"></a> |
|---|
| 33 | </div> |
|---|
| 34 | <div class="section" lang="en"> |
|---|
| 35 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> |
|---|
| 36 | <a name="bbv2.extending.toolset_modules"></a>Toolset modules</h2></div></div></div> |
|---|
| 37 | <p>If your extensions will be used only on one project, they can be |
|---|
| 38 | placed in a separate <code class="filename">.jam</code> file that will be |
|---|
| 39 | imported by your <code class="filename">project-root.jam</code>. If the |
|---|
| 40 | extensions will be used on many projects, users will thank you for |
|---|
| 41 | a finishing touch. |
|---|
| 42 | </p> |
|---|
| 43 | <p>The <code class="computeroutput">using</code> rule provides a standard mechanism |
|---|
| 44 | for loading and configuring extensions. To make it work, your module |
|---|
| 45 | |
|---|
| 46 | should provide an <code class="computeroutput">init</code> rule. The rule will be called |
|---|
| 47 | with the same parameters that were passed to the |
|---|
| 48 | <code class="computeroutput">using</code> rule. The set of allowed parameters is |
|---|
| 49 | determined by you. For example, you can allow the user to specify |
|---|
| 50 | paths, tool versions, and other options. |
|---|
| 51 | </p> |
|---|
| 52 | <p>Here are some guidelines that help to make Boost.Build more |
|---|
| 53 | consistent: |
|---|
| 54 | </p> |
|---|
| 55 | <div class="itemizedlist"><ul type="disc"> |
|---|
| 56 | <li><p>The <code class="computeroutput">init</code> rule should never fail. Even if |
|---|
| 57 | the user provided an incorrect path, you should emit a warning and go |
|---|
| 58 | on. Configuration may be shared between different machines, and |
|---|
| 59 | wrong values on one machine can be OK on another. |
|---|
| 60 | </p></li> |
|---|
| 61 | <li> |
|---|
| 62 | <p>Prefer specifying the command to be executed |
|---|
| 63 | to specifying the tool's installation path. First of all, this |
|---|
| 64 | gives more control: it's possible to specify |
|---|
| 65 | </p> |
|---|
| 66 | <pre class="programlisting"> |
|---|
| 67 | /usr/bin/g++-snapshot |
|---|
| 68 | time g++ |
|---|
| 69 | </pre> |
|---|
| 70 | <p> |
|---|
| 71 | as the command. Second, while some tools have a logical |
|---|
| 72 | "installation root", it's better if user doesn't have to remember whether |
|---|
| 73 | a specific tool requires a full command or a path. |
|---|
| 74 | </p> |
|---|
| 75 | </li> |
|---|
| 76 | <li> |
|---|
| 77 | <p>Check for multiple initialization. A user can try to |
|---|
| 78 | initialize the module several times. You need to check for this |
|---|
| 79 | and decide what to do. Typically, unless you support several |
|---|
| 80 | versions of a tool, duplicate initialization is a user error. |
|---|
| 81 | |
|---|
| 82 | If the |
|---|
| 83 | tool's version can be specified during initialization, make sure the |
|---|
| 84 | version is either always specified, or never specified (in which |
|---|
| 85 | case the tool is initialied only once). For example, if you allow: |
|---|
| 86 | </p> |
|---|
| 87 | <pre class="programlisting"> |
|---|
| 88 | using yfc ; |
|---|
| 89 | using yfc : 3.3 ; |
|---|
| 90 | using yfc : 3.4 ; |
|---|
| 91 | </pre> |
|---|
| 92 | <p> |
|---|
| 93 | Then it's not clear if the first initialization corresponds to |
|---|
| 94 | version 3.3 of the tool, version 3.4 of the tool, or some other |
|---|
| 95 | version. This can lead to building twice with the same version. |
|---|
| 96 | </p> |
|---|
| 97 | </li> |
|---|
| 98 | <li> |
|---|
| 99 | <p>If possible, <code class="computeroutput">init</code> must be callable |
|---|
| 100 | with no parameters. In which case, it should try to autodetect all |
|---|
| 101 | the necessary information, for example, by looking for a tool in |
|---|
| 102 | <code class="envar">PATH</code> or in common installation locations. Often this |
|---|
| 103 | is possible and allows the user to simply write: |
|---|
| 104 | </p> |
|---|
| 105 | <pre class="programlisting"> |
|---|
| 106 | using yfc ; |
|---|
| 107 | </pre> |
|---|
| 108 | </li> |
|---|
| 109 | <li><p>Consider using facilities in the |
|---|
| 110 | <code class="computeroutput">tools/common</code> module. You can take a look at how |
|---|
| 111 | <code class="computeroutput">tools/gcc.jam</code> uses that module in the <code class="computeroutput">init</code> rule. |
|---|
| 112 | </p></li> |
|---|
| 113 | </ul></div> |
|---|
| 114 | </div> |
|---|
| 115 | <table width="100%"><tr> |
|---|
| 116 | <td align="left"></td> |
|---|
| 117 | <td align="right"><small></small></td> |
|---|
| 118 | </tr></table> |
|---|
| 119 | <hr> |
|---|
| 120 | <div class="spirit-nav"> |
|---|
| 121 | <a accesskey="p" href="rules.html"><img src="../../images/prev.png" alt="Prev"></a><a accesskey="u" href="../extender.html"><img src="../../images/up.png" alt="Up"></a><a accesskey="h" href="../../index.html"><img src="../../images/home.png" alt="Home"></a><a accesskey="n" href="../reference.html"><img src="../../images/next.png" alt="Next"></a> |
|---|
| 122 | </div> |
|---|
| 123 | </body> |
|---|
| 124 | </html> |
|---|
