First attempt at Sphinx. Convert the Projects.html file to Sphinx format.
[oota-llvm.git] / docs / Projects.rst
1 .. _projects:
2
3 ========================
4 Creating an LLVM Project
5 ========================
6
7 .. contents::
8    :local:
9
10 Overview
11 ========
12
13 The LLVM build system is designed to facilitate the building of third party
14 projects that use LLVM header files, libraries, and tools.  In order to use
15 these facilities, a ``Makefile`` from a project must do the following things:
16
17 * Set ``make`` variables. There are several variables that a ``Makefile`` needs
18   to set to use the LLVM build system:
19
20   * ``PROJECT_NAME`` — The name by which your project is known.
21   * ``LLVM_SRC_ROOT`` — The root of the LLVM source tree.
22   * ``LLVM_OBJ_ROOT`` — The root of the LLVM object tree.
23   * ``PROJ_SRC_ROOT`` — The root of the project's source tree.
24   * ``PROJ_OBJ_ROOT`` — The root of the project's object tree.
25   * ``PROJ_INSTALL_ROOT`` — The root installation directory.
26   * ``LEVEL`` — The relative path from the current directory to the
27     project's root ``($PROJ_OBJ_ROOT)``.
28
29 * Include ``Makefile.config`` from ``$(LLVM_OBJ_ROOT)``.
30
31 * Include ``Makefile.rules`` from ``$(LLVM_SRC_ROOT)``.
32
33 There are two ways that you can set all of these variables:
34
35 * You can write your own ``Makefiles`` which hard-code these values.
36
37 * You can use the pre-made LLVM sample project. This sample project includes
38   ``Makefiles``, a configure script that can be used to configure the location
39   of LLVM, and the ability to support multiple object directories from a single
40   source directory.
41
42 This document assumes that you will base your project on the LLVM sample project
43 found in ``llvm/projects/sample``. If you want to devise your own build system,
44 studying the sample project and LLVM ``Makefiles`` will probably provide enough
45 information on how to write your own ``Makefiles``.
46
47 Create a Project from the Sample Project
48 ========================================
49
50 Follow these simple steps to start your project:
51
52 #. Copy the ``llvm/projects/sample`` directory to any place of your choosing.
53    You can place it anywhere you like. Rename the directory to match the name
54    of your project.
55
56 #. If you downloaded LLVM using Subversion, remove all the directories named
57    ``.svn`` (and all the files therein) from your project's new source tree.
58    This will keep Subversion from thinking that your project is inside
59    ``llvm/trunk/projects/sample``.
60
61 #. Add your source code and Makefiles to your source tree.
62
63 #. If you want your project to be configured with the ``configure`` script then
64    you need to edit ``autoconf/configure.ac`` as follows:
65
66    * **``AC_INIT``** — Place the name of your project, its version number
67      and a contact email address for your project as the arguments to this macro
68  
69    * **``AC_CONFIG_AUX_DIR``** — If your project isn't in the
70      ``llvm/projects`` directory then you might need to adjust this so that it
71      specifies a relative path to the ``llvm/autoconf`` directory.
72
73    * **``LLVM_CONFIG_PROJECT``** — Just leave this alone.
74
75    * **``AC_CONFIG_SRCDIR``** — Specify a path to a file name that
76      identifies your project; or just leave it at ``Makefile.common.in``.
77
78    * **``AC_CONFIG_FILES``** — Do not change.
79
80    * **``AC_CONFIG_MAKEFILE``** — Use one of these macros for each
81      Makefile that your project uses. This macro arranges for your makefiles to
82      be copied from the source directory, unmodified, to the build directory.
83
84 #. After updating ``autoconf/configure.ac``, regenerate the configure script
85    with these commands:
86
87 .. code-block:: bash
88
89    % cd autoconf
90    % ./AutoRegen.sh
91
92    You must be using Autoconf version 2.59 or later and your ``aclocal`` version
93    should be 1.9 or later.
94
95 #. Run ``configure`` in the directory in which you want to place object code.
96    Use the following options to tell your project where it can find LLVM:
97
98    ``--with-llvmsrc=<directory>``
99        Tell your project where the LLVM source tree is located.
100
101    ``--with-llvmobj=<directory>``
102        Tell your project where the LLVM object tree is located.
103
104    ``--prefix=<directory>``
105        Tell your project where it should get installed.
106
107 That's it!  Now all you have to do is type ``gmake`` (or ``make`` if your on a
108 GNU/Linux system) in the root of your object directory, and your project should
109 build.
110
111 Source Tree Layout
112 ==================
113
114 In order to use the LLVM build system, you will want to organize your source
115 code so that it can benefit from the build system's features.  Mainly, you want
116 your source tree layout to look similar to the LLVM source tree layout.  The
117 best way to do this is to just copy the project tree from
118 ``llvm/projects/sample`` and modify it to meet your needs, but you can certainly
119 add to it if you want.
120
121 Underneath your top level directory, you should have the following directories:
122
123 **``lib``**
124
125     This subdirectory should contain all of your library source code.  For each
126     library that you build, you will have one directory in **``lib``** that will
127     contain that library's source code.
128
129     Libraries can be object files, archives, or dynamic libraries.  The
130     **``lib``** directory is just a convenient place for libraries as it places
131     them all in a directory from which they can be linked later.
132
133 **``include``**
134
135     This subdirectory should contain any header files that are global to your
136     project. By global, we mean that they are used by more than one library or
137     executable of your project.
138
139     By placing your header files in **``include``**, they will be found
140     automatically by the LLVM build system.  For example, if you have a file
141     **``include/jazz/note.h``**, then your source files can include it simply
142     with **``#include "jazz/note.h"``**.
143
144 **``tools``**
145
146     This subdirectory should contain all of your source code for executables.
147     For each program that you build, you will have one directory in
148     **``tools``** that will contain that program's source code.
149
150 **``test``**
151
152     This subdirectory should contain tests that verify that your code works
153     correctly.  Automated tests are especially useful.
154
155     Currently, the LLVM build system provides basic support for tests. The LLVM
156     system provides the following:
157
158 * LLVM provides a ``tcl`` procedure that is used by ``Dejagnu`` to run tests.
159   It can be found in ``llvm/lib/llvm-dg.exp``.  This test procedure uses ``RUN``
160   lines in the actual test case to determine how to run the test.  See the
161   `TestingGuide`_TestingGuide.html for more details. You can easily write
162   Makefile support similar to the Makefiles in ``llvm/test`` to use ``Dejagnu``
163   to run your project's tests.
164
165 * LLVM contains an optional package called ``llvm-test``, which provides
166   benchmarks and programs that are known to compile with the Clang front
167   end. You can use these programs to test your code, gather statistical
168   information, and compare it to the current LLVM performance statistics.
169   
170   Currently, there is no way to hook your tests directly into the ``llvm/test``
171   testing harness. You will simply need to find a way to use the source
172   provided within that directory on your own.
173
174 Typically, you will want to build your **``lib``** directory first followed by
175 your **``tools``** directory.
176
177 Writing LLVM Style Makefiles
178 ============================
179
180 The LLVM build system provides a convenient way to build libraries and
181 executables.  Most of your project Makefiles will only need to define a few
182 variables.  Below is a list of the variables one can set and what they can
183 do:
184
185 Required Variables
186 ------------------
187
188 ``LEVEL``
189
190     This variable is the relative path from this ``Makefile`` to the top
191     directory of your project's source code.  For example, if your source code
192     is in ``/tmp/src``, then the ``Makefile`` in ``/tmp/src/jump/high``
193     would set ``LEVEL`` to ``"../.."``.
194
195 Variables for Building Subdirectories
196 -------------------------------------
197
198 ``DIRS``
199
200     This is a space separated list of subdirectories that should be built.  They
201     will be built, one at a time, in the order specified.
202
203 ``PARALLEL_DIRS``
204
205     This is a list of directories that can be built in parallel. These will be
206     built after the directories in DIRS have been built.
207
208 ``OPTIONAL_DIRS``
209
210     This is a list of directories that can be built if they exist, but will not
211     cause an error if they do not exist.  They are built serially in the order
212     in which they are listed.
213
214 Variables for Building Libraries
215 --------------------------------
216
217 ``LIBRARYNAME``
218
219     This variable contains the base name of the library that will be built.  For
220     example, to build a library named ``libsample.a``, ``LIBRARYNAME`` should
221     be set to ``sample``.
222
223 ``BUILD_ARCHIVE``
224
225     By default, a library is a ``.o`` file that is linked directly into a
226     program.  To build an archive (also known as a static library), set the
227     ``BUILD_ARCHIVE`` variable.
228
229 ``SHARED_LIBRARY``
230
231     If ``SHARED_LIBRARY`` is defined in your Makefile, a shared (or dynamic)
232     library will be built.
233
234 Variables for Building Programs
235 -------------------------------
236
237 ``TOOLNAME``
238
239     This variable contains the name of the program that will be built.  For
240     example, to build an executable named ``sample``, ``TOOLNAME`` should be set
241     to ``sample``.
242
243 ``USEDLIBS``
244
245     This variable holds a space separated list of libraries that should be
246     linked into the program.  These libraries must be libraries that come from
247     your **``lib``** directory.  The libraries must be specified without their
248     ``lib`` prefix.  For example, to link ``libsample.a``, you would set
249     ``USEDLIBS`` to ``sample.a``.
250
251     Note that this works only for statically linked libraries.
252
253 ``LLVMLIBS``
254
255     This variable holds a space separated list of libraries that should be
256     linked into the program.  These libraries must be LLVM libraries.  The
257     libraries must be specified without their ``lib`` prefix.  For example, to
258     link with a driver that performs an IR transformation you might set
259     ``LLVMLIBS`` to this minimal set of libraries ``LLVMSupport.a LLVMCore.a
260     LLVMBitReader.a LLVMAsmParser.a LLVMAnalysis.a LLVMTransformUtils.a
261     LLVMScalarOpts.a LLVMTarget.a``.
262
263     Note that this works only for statically linked libraries. LLVM is split
264     into a large number of static libraries, and the list of libraries you
265     require may be much longer than the list above. To see a full list of
266     libraries use: ``llvm-config --libs all``.  Using ``LINK_COMPONENTS`` as
267     described below, obviates the need to set ``LLVMLIBS``.
268
269 ``LINK_COMPONENTS``
270
271     This variable holds a space separated list of components that the LLVM
272     ``Makefiles`` pass to the ``llvm-config`` tool to generate a link line for
273     the program. For example, to link with all LLVM libraries use
274     ``LINK_COMPONENTS = all``.
275
276 ``LIBS``
277
278     To link dynamic libraries, add <tt>-l&lt;library base name&gt;</tt> to the
279     ``LIBS`` variable.  The LLVM build system will look in the same places for
280     dynamic libraries as it does for static libraries.
281
282     For example, to link ``libsample.so``, you would have the following line in
283     your ``Makefile``:
284
285 .. code-block: Makefile
286
287   LIBS += -lsample
288
289 Note that ``LIBS`` must occur in the Makefile after the inclusion of
290 ``Makefile.common``.
291
292 Miscellaneous Variables
293 -----------------------
294
295 ``CFLAGS``
296 ``CPPFLAGS``
297
298     This variable can be used to add options to the C and C++ compiler,
299     respectively.  It is typically used to add options that tell the compiler
300     the location of additional directories to search for header files.
301
302     It is highly suggested that you append to ``CFLAGS`` and ``CPPFLAGS`` as
303     opposed to overwriting them.  The master ``Makefiles`` may already have
304     useful options in them that you may not want to overwrite.
305
306 Placement of Object Code
307 ========================
308
309 The final location of built libraries and executables will depend upon whether
310 you do a ``Debug``, ``Release``, or ``Profile`` build.
311
312 Libraries
313
314     All libraries (static and dynamic) will be stored in
315     ``PROJ_OBJ_ROOT/<type>/lib``, where *``type``* is ``Debug``, ``Release``, or
316     ``Profile`` for a debug, optimized, or profiled build, respectively.
317
318 Executables
319
320     All executables will be stored in ``PROJ_OBJ_ROOT/<type>/bin``, where
321     *``type``* is ``Debug``, ``Release``, or ``Profile`` for a debug, optimized,
322     or profiled build, respectively.
323
324 Further Help
325 ============
326
327 If you have any questions or need any help creating an LLVM project, the LLVM
328 team would be more than happy to help.  You can always post your questions to
329 the `LLVM Developers Mailing List`_http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev.