path: root/docs/MakefileGuide.rst

===================
LLVM Makefile Guide
===================

.. contents::
   :local:

Introduction
============

This document provides *usage* information about the LLVM makefile system. While
loosely patterned after the BSD makefile system, LLVM has taken a departure from
BSD in order to implement additional features needed by LLVM.  Although makefile
systems, such as ``automake``, were attempted at one point, it has become clear
that the features needed by LLVM and the ``Makefile`` norm are too great to use
a more limited tool. Consequently, LLVM requires simply GNU Make 3.79, a widely
portable makefile processor. LLVM unabashedly makes heavy use of the features of
GNU Make so the dependency on GNU Make is firm. If you're not familiar with
``make``, it is recommended that you read the `GNU Makefile Manual
<http://www.gnu.org/software/make/manual/make.html>`_.

While this document is rightly part of the `LLVM Programmer's
Manual <ProgrammersManual.html>`_, it is treated separately here because of the
volume of content and because it is often an early source of bewilderment for
new developers.

General Concepts
================

The LLVM Makefile System is the component of LLVM that is responsible for
building the software, testing it, generating distributions, checking those
distributions, installing and uninstalling, etc. It consists of a several files
throughout the source tree. These files and other general concepts are described
in this section.

Projects
--------

The LLVM Makefile System is quite generous. It not only builds its own software,
but it can build yours too. Built into the system is knowledge of the
``llvm/projects`` directory. Any directory under ``projects`` that has both a
``configure`` script and a ``Makefile`` is assumed to be a project that uses the
LLVM Makefile system.  Building software that uses LLVM does not require the
LLVM Makefile System nor even placement in the ``llvm/projects``
directory. However, doing so will allow your project to get up and running
quickly by utilizing the built-in features that are used to compile LLVM. LLVM
compiles itself using the same features of the makefile system as used for
projects.

For complete details on setting up your projects configuration, simply mimic the
``llvm/projects/sample`` project. Or for further details, consult the
`Projects <Projects.html>`_ page.

Variable Values
---------------

To use the makefile system, you simply create a file named ``Makefile`` in your
directory and declare values for certain variables.  The variables and values
that you select determine what the makefile system will do. These variables
enable rules and processing in the makefile system that automatically Do The
Right Thing (C).

Including Makefiles
-------------------

Setting variables alone is not enough. You must include into your Makefile
additional files that provide the rules of the LLVM Makefile system. The various
files involved are described in the sections that follow.

``Makefile``
^^^^^^^^^^^^

Each directory to participate in the build needs to have a file named
``Makefile``. This is the file first read by ``make``. It has three
sections:

#. Settable Variables --- Required that must be set first.
#. ``include $(LEVEL)/Makefile.common`` --- include the LLVM Makefile system.
#. Override Variables --- Override variables set by the LLVM Makefile system.

.. _$(LEVEL)/Makefile.common:

``Makefile.common``
^^^^^^^^^^^^^^^^^^^

Every project must have a ``Makefile.common`` file at its top source
directory. This file serves three purposes:

#. It includes the project's configuration makefile to obtain values determined
   by the ``configure`` script. This is done by including the
   `$(LEVEL)/Makefile.config`_ file.

#. It specifies any other (static) values that are needed throughout the
   project. Only values that are used in all or a large proportion of the
   project's directories should be placed here.

#. It includes the standard rules for the LLVM Makefile system,
   `$(LLVM_SRC_ROOT)/Makefile.rules`_.  This file is the *guts* of the LLVM
   ``Makefile`` system.

.. _$(LEVEL)/Makefile.config:

``Makefile.config``
^^^^^^^^^^^^^^^^^^^

Every project must have a ``Makefile.config`` at the top of its *build*
directory. This file is **generated** by the ``configure`` script from the
pattern provided by the ``Makefile.config.in`` file located at the top of the
project's *source* directory. The contents of this file depend largely on what
configuration items the project uses, however most projects can get what they
need by just relying on LLVM's configuration found in
``$(LLVM_OBJ_ROOT)/Makefile.config``.

.. _$(LLVM_SRC_ROOT)/Makefile.rules:

``Makefile.rules``
^^^^^^^^^^^^^^^^^^

This file, located at ``$(LLVM_SRC_ROOT)/Makefile.rules`` is the heart of the
LLVM Makefile System. It provides all the logic, dependencies, and rules for
building the targets supported by the system. What it does largely depends on
the values of ``make`` `variables`_ that have been set *before*
``Makefile.rules`` is included.

Comments
^^^^^^^^

User ``Makefile``\s need not have comments in them unless the construction is
unusual or it does not strictly follow the rules and patterns of the LLVM
makefile system. Makefile comments are invoked with the pound (``#``) character.
The ``#`` character and any text following it, to the end of the line, are
ignored by ``make``.

Tutorial
========

This section provides some examples of the different kinds of modules you can
build with the LLVM makefile system. In general, each directory you provide will
build a single object although that object may be composed of additionally
compiled components.

Libraries
---------

Only a few variable definitions are needed to build a regular library.
Normally, the makefile system will build all the software into a single
``libname.o`` (pre-linked) object. This means the library is not searchable and
that the distinction between compilation units has been dissolved. Optionally,
you can ask for a shared library (.so) or archive library (.a) built.  Archive
libraries are the default. For example:

.. code-block:: makefile

  LIBRARYNAME = mylib
  SHARED_LIBRARY = 1
  ARCHIVE_LIBRARY = 1

says to build a library named ``mylib`` with both a shared library
(``mylib.so``) and an archive library (``mylib.a``) version. The contents of all
the libraries produced will be the same, they are just constructed differently.
Note that you normally do not need to specify the sources involved. The LLVM
Makefile system will infer the source files from the contents of the source
directory.

The ``LOADABLE_MODULE=1`` directive can be used in conjunction with
``SHARED_LIBRARY=1`` to indicate that the resulting shared library should be
openable with the ``dlopen`` function and searchable with the ``dlsym`` function
(or your operating system's equivalents). While this isn't strictly necessary on
Linux and a few other platforms, it is required on systems like HP-UX and
Darwin. You should use ``LOADABLE_MODULE`` for any shared library that you
intend to be loaded into an tool via the ``-load`` option.  `Pass documentation
<writing-an-llvm-pass-makefile>`_ has an example of why you might want to do
this.

Bitcode Modules
^^^^^^^^^^^^^^^

In some situations, it is desirable to build a single bitcode module from a
variety of sources, instead of an archive, shared library, or bitcode
library. Bitcode modules can be specified in addition to any of the other types
of libraries by defining the `MODULE_NAME`_ variable. For example:

.. code-block:: makefile

  LIBRARYNAME = mylib
  BYTECODE_LIBRARY = 1
  MODULE_NAME = mymod

will build a module named ``mymod.bc`` from the sources in the directory. This
module will be an aggregation of all the bitcode modules derived from the
sources. The example will also build a bitcode archive containing a bitcode
module for each compiled source file. The difference is subtle, but important
depending on how the module or library is to be linked.

Loadable Modules
^^^^^^^^^^^^^^^^

In some situations, you need to create a loadable module. Loadable modules can
be loaded into programs like ``opt`` or ``llc`` to specify additional passes to
run or targets to support.  Loadable modules are also useful for debugging a
pass or providing a pass with another package if that pass can't be included in
LLVM.

LLVM provides complete support for building such a module. All you need to do is
use the ``LOADABLE_MODULE`` variable in your ``Makefile``. For example, to build
a loadable module named ``MyMod`` that uses the LLVM libraries ``LLVMSupport.a``
and ``LLVMSystem.a``, you would specify:

.. code-block:: makefile

  LIBRARYNAME := MyMod
  LOADABLE_MODULE := 1
  LINK_COMPONENTS := support system

Use of the ``LOADABLE_MODULE`` facility implies several things:

#. There will be no "``lib``" prefix on the module. This differentiates it from
    a standard shared library of the same name.

#. The `SHARED_LIBRARY`_ variable is turned on.

#. The `LINK_LIBS_IN_SHARED`_ variable is turned on.

A loadable module is loaded by LLVM via the facilities of libtool's libltdl
library which is part of ``lib/System`` implementation.

Tools
-----

For building executable programs (tools), you must provide the name of the tool
and the names of the libraries you wish to link with the tool. For example:

.. code-block:: makefile

  TOOLNAME = mytool
  USEDLIBS = mylib
  LINK_COMPONENTS = support system

says that we are to build a tool name ``mytool`` and that it requires three
libraries: ``mylib``, ``LLVMSupport.a`` and ``LLVMSystem.a``.

Note that two different variables are used to indicate which libraries are
linked: ``USEDLIBS`` and ``LLVMLIBS``. This distinction is necessary to support
projects. ``LLVMLIBS`` refers to the LLVM libraries found in the LLVM object
directory. ``USEDLIBS`` refers to the libraries built by your project. In the
case of building LLVM tools, ``USEDLIBS`` and ``LLVMLIBS`` can be used
interchangeably since the "project" is LLVM itself and ``USEDLIBS`` refers to
the same place as ``LLVMLIBS``.

Also note that there are two different ways of specifying a library: with a
``.a`` suffix and without. Without the suffix, the entry refers to the re-linked
(.o) file which will include *all* symbols of the library.  This is
useful, for example, to include all passes from a library of passes.  If the
``.a`` suffix is used then the library is linked as a searchable library (with
the ``-l`` option). In this case, only the symbols that are unresolved *at
that point* will be resolved from the library, if they exist. Other
(unreferenced) symbols will not be included when the ``.a`` syntax is used. Note
that in order to use the ``.a`` suffix, the library in question must have been
built with the ``ARCHIVE_LIBRARY`` option set.

JIT Tools
^^^^^^^^^

Many tools will want to use the JIT features of LLVM.  To do this, you simply
specify that you want an execution 'engine', and the makefiles will
automatically link in the appropriate JIT for the host or an interpreter if none
is available:

.. code-block:: makefile

  TOOLNAME = my_jit_tool
  USEDLIBS = mylib
  LINK_COMPONENTS = engine

Of course, any additional libraries may be listed as other components.  To get a
full understanding of how this changes the linker command, it is recommended
that you:

.. code-block:: bash

  % cd examples/Fibonacci
  % make VERBOSE=1

Targets Supported
=================

This section describes each of the targets that can be built using the LLVM
Makefile system. Any target can be invoked from any directory but not all are
applicable to a given directory (e.g. "check", "dist" and "install" will always
operate as if invoked from the top level directory).

================= ===============      ==================
Target Name       Implied Targets      Target Description
================= ===============      ==================
``all``           \                    Compile the software recursively. Default target.
``all-local``     \                    Compile the software in the local directory only.
``check``         \                    Change to the ``test`` directory in a project and run the test suite there.
``check-local``   \                    Run a local test suite. Generally this is only defined in the  ``Makefile`` of the project's ``test`` directory.
``clean``         \                    Remove built objects recursively.
``clean-local``   \                    Remove built objects from the local directory only.
``dist``          ``all``              Prepare a source distribution tarball.
``dist-check``    ``all``              Prepare a source distribution tarball and check that it builds.
``dist-clean``    ``clean``            Clean source distribution tarball temporary files.
``install``       ``all``              Copy built objects to installation directory.
``preconditions`` ``all``              Check to make sure configuration and makefiles are up to date.
``printvars``     ``all``              Prints variables defined by the makefile system (for debugging).
``tags``          \                    Make C and C++ tags files for emacs and vi.
``uninstall``     \                    Remove built objects from installation directory.
================= ===============      ==================

.. _all:

``all`` (default)
-----------------

When you invoke ``make`` with no arguments, you are implicitly instructing it to
seek the ``all`` target (goal). This target is used for building the software
recursively and will do different things in different directories.  For example,
in a ``lib`` directory, the ``all`` target will compile source files and
generate libraries. But, in a ``tools`` directory, it will link libraries and
generate executables.

``all-local``
-------------

This target is the same as `all`_ but it operates only on the current directory
instead of recursively.

``check``
---------

This target can be invoked from anywhere within a project's directories but
always invokes the `check-local`_ target in the project's ``test`` directory, if
it exists and has a ``Makefile``. A warning is produced otherwise.  If
`TESTSUITE`_ is defined on the ``make`` command line, it will be passed down to
the invocation of ``make check-local`` in the ``test`` directory. The intended
usage for this is to assist in running specific suites of tests. If
``TESTSUITE`` is not set, the implementation of ``check-local`` should run all
normal tests.  It is up to the project to define what different values for
``TESTSUTE`` will do. See the :doc:`Testing Guide <TestingGuide>` for further
details.

``check-local``
---------------

This target should be implemented by the ``Makefile`` in the project's ``test``
directory. It is invoked by the ``check`` target elsewhere.  Each project is
free to define the actions of ``check-local`` as appropriate for that
project. The LLVM project itself uses dejagnu to run a suite of feature and
regression tests. Other projects may choose to use dejagnu or any other testing
mechanism.

``clean``
---------

This target cleans the build directory, recursively removing all things that the
Makefile builds. The cleaning rules have been made guarded so they shouldn't go
awry (via ``rm -f $(UNSET_VARIABLE)/*`` which will attempt to erase the entire
directory structure).

``clean-local``
---------------

This target does the same thing as ``clean`` but only for the current (local)
directory.

``dist``
--------

This target builds a distribution tarball. It first builds the entire project
using the ``all`` target and then tars up the necessary files and compresses
it. The generated tarball is sufficient for a casual source distribution, but
probably not for a release (see ``dist-check``).

``dist-check``
--------------

This target does the same thing as the ``dist`` target but also checks the
distribution tarball. The check is made by unpacking the tarball to a new
directory, configuring it, building it, installing it, and then verifying that
the installation results are correct (by comparing to the original build).  This
target can take a long time to run but should be done before a release goes out
to make sure that