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 provides a ``tcl`` procedure that is used by ``Dejagnu`` to run tests.
 155   It can be found in ``llvm/lib/llvm-dg.exp``.  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. You can easily write Makefile
 158   support similar to the Makefiles in ``llvm/test`` to use ``Dejagnu`` to
 159   run your project's tests.
 160
 161 * LLVM contains an optional package called ``llvm-test``, which provides
 162   benchmarks and programs that are known to compile with the Clang front
 163   end. You can use these programs to test your code, gather statistical
 164   information, and compare it to the current LLVM performance statistics.
 165
 166   Currently, there is no way to hook your tests directly into the ``llvm/test``
 167   testing harness. You will simply need to find a way to use the source
 168   provided within that directory on your own.
 169
 170 Typically, you will want to build your **lib** directory first followed by your
 171 **tools** directory.
 172
 173 Writing LLVM Style Makefiles
 174 ============================
 175
 176 The LLVM build system provides a convenient way to build libraries and
 177 executables.  Most of your project Makefiles will only need to define a few
 178 variables.  Below is a list of the variables one can set and what they can
 179 do:
 180
 181 Required Variables
 182 ------------------
 183
 184 ``LEVEL``
 185
 186     This variable is the relative path from this ``Makefile`` to the top
 187     directory of your project's source code.  For example, if your source code
 188     is in ``/tmp/src``, then the ``Makefile`` in ``/tmp/src/jump/high``
 189     would set ``LEVEL`` to ``"../.."``.
 190
 191 Variables for Building Subdirectories
 192 -------------------------------------
 193
 194 ``DIRS``
 195
 196     This is a space separated list of subdirectories that should be built.  They
 197     will be built, one at a time, in the order specified.
 198
 199 ``PARALLEL_DIRS``
 200
 201     This is a list of directories that can be built in parallel. These will be
 202     built after the directories in DIRS have been built.
 203
 204 ``OPTIONAL_DIRS``
 205
 206     This is a list of directories that can be built if they exist, but will not
 207     cause an error if they do not exist.  They are built serially in the order
 208     in which they are listed.
 209
 210 Variables for Building Libraries
 211 --------------------------------
 212
 213 ``LIBRARYNAME``
 214
 215     This variable contains the base name of the library that will be built.  For
 216     example, to build a library named ``libsample.a``, ``LIBRARYNAME`` should
 217     be set to ``sample``.
 218
 219 ``BUILD_ARCHIVE``
 220
 221     By default, a library is a ``.o`` file that is linked directly into a
 222     program.  To build an archive (also known as a static library), set the
 223     ``BUILD_ARCHIVE`` variable.
 224
 225 ``SHARED_LIBRARY``
 226
 227     If ``SHARED_LIBRARY`` is defined in your Makefile, a shared (or dynamic)
 228     library will be built.
 229
 230 Variables for Building Programs
 231 -------------------------------
 232
 233 ``TOOLNAME``
 234
 235     This variable contains the name of the program that will be built.  For
 236     example, to build an executable named ``sample``, ``TOOLNAME`` should be set
 237     to ``sample``.
 238
 239 ``USEDLIBS``
 240
 241     This variable holds a space separated list of libraries that should be
 242     linked into the program.  These libraries must be libraries that come from
 243     your **lib** directory.  The libraries must be specified without their
 244     ``lib`` prefix.  For example, to link ``libsample.a``, you would set
 245     ``USEDLIBS`` to ``sample.a``.
 246
 247     Note that this works only for statically linked libraries.
 248
 249 ``LLVMLIBS``
 250
 251     This variable holds a space separated list of libraries that should be
 252     linked into the program.  These libraries must be LLVM libraries.  The
 253     libraries must be specified without their ``lib`` prefix.  For example, to
 254     link with a driver that performs an IR transformation you might set
 255     ``LLVMLIBS`` to this minimal set of libraries ``LLVMSupport.a LLVMCore.a
 256     LLVMBitReader.a LLVMAsmParser.a LLVMAnalysis.a LLVMTransformUtils.a
 257     LLVMScalarOpts.a LLVMTarget.a``.
 258
 259     Note that this works only for statically linked libraries. LLVM is split
 260     into a large number of static libraries, and the list of libraries you
 261     require may be much longer than the list above. To see a full list of
 262     libraries use: ``llvm-config --libs all``.  Using ``LINK_COMPONENTS`` as
 263     described below, obviates the need to set ``LLVMLIBS``.
 264
 265 ``LINK_COMPONENTS``
 266
 267     This variable holds a space separated list of components that the LLVM
 268     ``Makefiles`` pass to the ``llvm-config`` tool to generate a link line for
 269     the program. For example, to link with all LLVM libraries use
 270     ``LINK_COMPONENTS = all``.
 271
 272 ``LIBS``
 273
 274     To link dynamic libraries, add ``-l<library base name>`` to the ``LIBS``
 275     variable.  The LLVM build system will look in the same places for dynamic
 276     libraries as it does for static libraries.
 277
 278     For example, to link ``libsample.so``, you would have the following line in
 279     your ``Makefile``:
 280
 281         .. code-block:: makefile
 282
 283           LIBS += -lsample
 284
 285 Note that ``LIBS`` must occur in the Makefile after the inclusion of
 286 ``Makefile.common``.
 287
 288 Miscellaneous Variables
 289 -----------------------
 290
 291 ``CFLAGS`` & ``CPPFLAGS``
 292
 293     This variable can be used to add options to the C and C++ compiler,
 294     respectively.  It is typically used to add options that tell the compiler
 295     the location of additional directories to search for header files.
 296
 297     It is highly suggested that you append to ``CFLAGS`` and ``CPPFLAGS`` as
 298     opposed to overwriting them.  The master ``Makefiles`` may already have
 299     useful options in them that you may not want to overwrite.
 300
 301 Placement of Object Code
 302 ========================
 303
 304 The final location of built libraries and executables will depend upon whether
 305 you do a ``Debug``, ``Release``, or ``Profile`` build.
 306
 307 Libraries
 308
 309     All libraries (static and dynamic) will be stored in
 310     ``PROJ_OBJ_ROOT/<type>/lib``, where *type* is ``Debug``, ``Release``, or
 311     ``Profile`` for a debug, optimized, or profiled build, respectively.
 312
 313 Executables
 314
 315     All executables will be stored in ``PROJ_OBJ_ROOT/<type>/bin``, where *type*
 316     is ``Debug``, ``Release``, or ``Profile`` for a debug, optimized, or
 317     profiled build, respectively.
 318
 319 Further Help
 320 ============
 321
 322 If you have any questions or need any help creating an LLVM project, the LLVM
 323 team would be more than happy to help.  You can always post your questions to
 324 the `LLVM Developers Mailing List
 325 <http://lists.cs.uiuc.edu/pipermail/llvmdev/>`_.