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