11 This document provides *usage* information about the LLVM makefile system. While
12 loosely patterned after the BSD makefile system, LLVM has taken a departure from
13 BSD in order to implement additional features needed by LLVM. Although makefile
14 systems, such as ``automake``, were attempted at one point, it has become clear
15 that the features needed by LLVM and the ``Makefile`` norm are too great to use
16 a more limited tool. Consequently, LLVM requires simply GNU Make 3.79, a widely
17 portable makefile processor. LLVM unabashedly makes heavy use of the features of
18 GNU Make so the dependency on GNU Make is firm. If you're not familiar with
19 ``make``, it is recommended that you read the `GNU Makefile Manual
20 <http://www.gnu.org/software/make/manual/make.html>`_.
22 While this document is rightly part of the `LLVM Programmer's
23 Manual <ProgrammersManual.html>`_, it is treated separately here because of the
24 volume of content and because it is often an early source of bewilderment for
30 The LLVM Makefile System is the component of LLVM that is responsible for
31 building the software, testing it, generating distributions, checking those
32 distributions, installing and uninstalling, etc. It consists of a several files
33 throughout the source tree. These files and other general concepts are described
39 The LLVM Makefile System is quite generous. It not only builds its own software,
40 but it can build yours too. Built into the system is knowledge of the
41 ``llvm/projects`` directory. Any directory under ``projects`` that has both a
42 ``configure`` script and a ``Makefile`` is assumed to be a project that uses the
43 LLVM Makefile system. Building software that uses LLVM does not require the
44 LLVM Makefile System nor even placement in the ``llvm/projects``
45 directory. However, doing so will allow your project to get up and running
46 quickly by utilizing the built-in features that are used to compile LLVM. LLVM
47 compiles itself using the same features of the makefile system as used for
50 For complete details on setting up your projects configuration, simply mimic the
51 ``llvm/projects/sample`` project. Or for further details, consult the
52 `Projects <Projects.html>`_ page.
57 To use the makefile system, you simply create a file named ``Makefile`` in your
58 directory and declare values for certain variables. The variables and values
59 that you select determine what the makefile system will do. These variables
60 enable rules and processing in the makefile system that automatically Do The
66 Setting variables alone is not enough. You must include into your Makefile
67 additional files that provide the rules of the LLVM Makefile system. The various
68 files involved are described in the sections that follow.
73 Each directory to participate in the build needs to have a file named
74 ``Makefile``. This is the file first read by ``make``. It has three
77 #. Settable Variables --- Required that must be set first.
78 #. ``include $(LEVEL)/Makefile.common`` --- include the LLVM Makefile system.
79 #. Override Variables --- Override variables set by the LLVM Makefile system.
81 .. _$(LEVEL)/Makefile.common:
86 Every project must have a ``Makefile.common`` file at its top source
87 directory. This file serves three purposes:
89 #. It includes the project's configuration makefile to obtain values determined
90 by the ``configure`` script. This is done by including the
91 `$(LEVEL)/Makefile.config`_ file.
93 #. It specifies any other (static) values that are needed throughout the
94 project. Only values that are used in all or a large proportion of the
95 project's directories should be placed here.
97 #. It includes the standard rules for the LLVM Makefile system,
98 `$(LLVM_SRC_ROOT)/Makefile.rules`_. This file is the *guts* of the LLVM
101 .. _$(LEVEL)/Makefile.config:
106 Every project must have a ``Makefile.config`` at the top of its *build*
107 directory. This file is **generated** by the ``configure`` script from the
108 pattern provided by the ``Makefile.config.in`` file located at the top of the
109 project's *source* directory. The contents of this file depend largely on what
110 configuration items the project uses, however most projects can get what they
111 need by just relying on LLVM's configuration found in
112 ``$(LLVM_OBJ_ROOT)/Makefile.config``.
114 .. _$(LLVM_SRC_ROOT)/Makefile.rules:
119 This file, located at ``$(LLVM_SRC_ROOT)/Makefile.rules`` is the heart of the
120 LLVM Makefile System. It provides all the logic, dependencies, and rules for
121 building the targets supported by the system. What it does largely depends on
122 the values of ``make`` `variables`_ that have been set *before*
123 ``Makefile.rules`` is included.
128 User ``Makefile``\s need not have comments in them unless the construction is
129 unusual or it does not strictly follow the rules and patterns of the LLVM
130 makefile system. Makefile comments are invoked with the pound (``#``) character.
131 The ``#`` character and any text following it, to the end of the line, are
137 This section provides some examples of the different kinds of modules you can
138 build with the LLVM makefile system. In general, each directory you provide will
139 build a single object although that object may be composed of additionally
145 Only a few variable definitions are needed to build a regular library.
146 Normally, the makefile system will build all the software into a single
147 ``libname.o`` (pre-linked) object. This means the library is not searchable and
148 that the distinction between compilation units has been dissolved. Optionally,
149 you can ask for a shared library (.so) or archive library (.a) built. Archive
150 libraries are the default. For example:
152 .. code-block:: makefile
158 says to build a library named ``mylib`` with both a shared library
159 (``mylib.so``) and an archive library (``mylib.a``) version. The contents of all
160 the libraries produced will be the same, they are just constructed differently.
161 Note that you normally do not need to specify the sources involved. The LLVM
162 Makefile system will infer the source files from the contents of the source
165 The ``LOADABLE_MODULE=1`` directive can be used in conjunction with
166 ``SHARED_LIBRARY=1`` to indicate that the resulting shared library should be
167 openable with the ``dlopen`` function and searchable with the ``dlsym`` function
168 (or your operating system's equivalents). While this isn't strictly necessary on
169 Linux and a few other platforms, it is required on systems like HP-UX and
170 Darwin. You should use ``LOADABLE_MODULE`` for any shared library that you
171 intend to be loaded into an tool via the ``-load`` option. `Pass documentation
172 <writing-an-llvm-pass-makefile>`_ has an example of why you might want to do
178 In some situations, it is desirable to build a single bitcode module from a
179 variety of sources, instead of an archive, shared library, or bitcode
180 library. Bitcode modules can be specified in addition to any of the other types
181 of libraries by defining the `MODULE_NAME`_ variable. For example:
183 .. code-block:: makefile
189 will build a module named ``mymod.bc`` from the sources in the directory. This
190 module will be an aggregation of all the bitcode modules derived from the
191 sources. The example will also build a bitcode archive containing a bitcode
192 module for each compiled source file. The difference is subtle, but important
193 depending on how the module or library is to be linked.
198 In some situations, you need to create a loadable module. Loadable modules can
199 be loaded into programs like ``opt`` or ``llc`` to specify additional passes to
200 run or targets to support. Loadable modules are also useful for debugging a
201 pass or providing a pass with another package if that pass can't be included in
204 LLVM provides complete support for building such a module. All you need to do is
205 use the ``LOADABLE_MODULE`` variable in your ``Makefile``. For example, to build
206 a loadable module named ``MyMod`` that uses the LLVM libraries ``LLVMSupport.a``
207 and ``LLVMSystem.a``, you would specify:
209 .. code-block:: makefile
213 LINK_COMPONENTS := support system
215 Use of the ``LOADABLE_MODULE`` facility implies several things:
217 #. There will be no "``lib``" prefix on the module. This differentiates it from
218 a standard shared library of the same name.
220 #. The `SHARED_LIBRARY`_ variable is turned on.
222 #. The `LINK_LIBS_IN_SHARED`_ variable is turned on.
224 A loadable module is loaded by LLVM via the facilities of libtool's libltdl
225 library which is part of ``lib/System`` implementation.
230 For building executable programs (tools), you must provide the name of the tool
231 and the names of the libraries you wish to link with the tool. For example:
233 .. code-block:: makefile
237 LINK_COMPONENTS = support system
239 says that we are to build a tool name ``mytool`` and that it requires three
240 libraries: ``mylib``, ``LLVMSupport.a`` and ``LLVMSystem.a``.
242 Note that two different variables are used to indicate which libraries are
243 linked: ``USEDLIBS`` and ``LLVMLIBS``. This distinction is necessary to support
244 projects. ``LLVMLIBS`` refers to the LLVM libraries found in the LLVM object
245 directory. ``USEDLIBS`` refers to the libraries built by your project. In the
246 case of building LLVM tools, ``USEDLIBS`` and ``LLVMLIBS`` can be used
247 interchangeably since the "project" is LLVM itself and ``USEDLIBS`` refers to
248 the same place as ``LLVMLIBS``.
250 Also note that there are two different ways of specifying a library: with a
251 ``.a`` suffix and without. Without the suffix, the entry refers to the re-linked
252 (.o) file which will include *all* symbols of the library. This is
253 useful, for example, to include all passes from a library of passes. If the
254 ``.a`` suffix is used then the library is linked as a searchable library (with
255 the ``-l`` option). In this case, only the symbols that are unresolved *at
256 that point* will be resolved from the library, if they exist. Other
257 (unreferenced) symbols will not be included when the ``.a`` syntax is used. Note
258 that in order to use the ``.a`` suffix, the library in question must have been
259 built with the ``ARCHIVE_LIBRARY`` option set.
264 Many tools will want to use the JIT features of LLVM. To do this, you simply
265 specify that you want an execution 'engine', and the makefiles will
266 automatically link in the appropriate JIT for the host or an interpreter if none
269 .. code-block:: makefile
271 TOOLNAME = my_jit_tool
273 LINK_COMPONENTS = engine
275 Of course, any additional libraries may be listed as other components. To get a
276 full understanding of how this changes the linker command, it is recommended
281 % cd examples/Fibonacci
287 This section describes each of the targets that can be built using the LLVM
288 Makefile system. Any target can be invoked from any directory but not all are
289 applicable to a given directory (e.g. "check", "dist" and "install" will always
290 operate as if invoked from the top level directory).
292 ================= =============== ==================
293 Target Name Implied Targets Target Description
294 ================= =============== ==================
295 ``all`` \ Compile the software recursively. Default target.
296 ``all-local`` \ Compile the software in the local directory only.
297 ``check`` \ Change to the ``test`` directory in a project and run the test suite there.
298 ``check-local`` \ Run a local test suite. Generally this is only defined in the ``Makefile`` of the project's ``test`` directory.
299 ``clean`` \ Remove built objects recursively.
300 ``clean-local`` \ Remove built objects from the local directory only.
301 ``dist`` ``all`` Prepare a source distribution tarball.
302 ``dist-check`` ``all`` Prepare a source distribution tarball and check that it builds.
303 ``dist-clean`` ``clean`` Clean source distribution tarball temporary files.
304 ``install`` ``all`` Copy built objects to installation directory.
305 ``preconditions`` ``all`` Check to make sure configuration and makefiles are up to date.
306 ``printvars`` ``all`` Prints variables defined by the makefile system (for debugging).
307 ``tags`` \ Make C and C++ tags files for emacs and vi.
308 ``uninstall`` \ Remove built objects from installation directory.
309 ================= =============== ==================
316 When you invoke ``make`` with no arguments, you are implicitly instructing it to
317 seek the ``all`` target (goal). This target is used for building the software
318 recursively and will do different things in different directories. For example,
319 in a ``lib`` directory, the ``all`` target will compile source files and
320 generate libraries. But, in a ``tools`` directory, it will link libraries and
321 generate executables.
326 This target is the same as `all`_ but it operates only on the current directory
327 instead of recursively.
332 This target can be invoked from anywhere within a project's directories but
333 always invokes the `check-local`_ target in the project's ``test`` directory, if
334 it exists and has a ``Makefile``. A warning is produced otherwise. If
335 `TESTSUITE`_ is defined on the ``make`` command line, it will be passed down to
336 the invocation of ``make check-local`` in the ``test`` directory. The intended
337 usage for this is to assist in running specific suites of tests. If
338 ``TESTSUITE`` is not set, the implementation of ``check-local`` should run all
339 normal tests. It is up to the project to define what different values for
340 ``TESTSUTE`` will do. See the :doc:`Testing Guide <TestingGuide>` for further
346 This target should be implemented by the ``Makefile`` in the project's ``test``
347 directory. It is invoked by the ``check`` target elsewhere. Each project is
348 free to define the actions of ``check-local`` as appropriate for that
349 project. The LLVM project itself uses the :doc:`Lit <CommandGuide/lit>` testing
350 tool to run a suite of feature and regression tests. Other projects may choose
351 to use :program:`lit` or any other testing mechanism.
356 This target cleans the build directory, recursively removing all things that the
357 Makefile builds. The cleaning rules have been made guarded so they shouldn't go
358 awry (via ``rm -f $(UNSET_VARIABLE)/*`` which will attempt to erase the entire
359 directory structure).
364 This target does the same thing as ``clean`` but only for the current (local)
370 This target builds a distribution tarball. It first builds the entire project
371 using the ``all`` target and then tars up the necessary files and compresses
372 it. The generated tarball is sufficient for a casual source distribution, but
373 probably not for a release (see ``dist-check``).
378 This target does the same thing as the ``dist`` target but also checks the
379 distribution tarball. The check is made by unpacking the tarball to a new
380 directory, configuring it, building it, installing it, and then verifying that
381 the installation results are correct (by comparing to the original build). This
382 target can take a long time to run but should be done before a release goes out
383 to make sure that the distributed tarball can actually be built into a working
389 This is a special form of the ``clean`` clean target. It performs a normal
390 ``clean`` but also removes things pertaining to building the distribution.
395 This target finalizes shared objects and executables and copies all libraries,
396 headers, executables and documentation to the directory given with the
397 ``--prefix`` option to ``configure``. When completed, the prefix directory will
398 have everything needed to **use** LLVM.
400 The LLVM makefiles can generate complete **internal** documentation for all the
401 classes by using ``doxygen``. By default, this feature is **not** enabled
402 because it takes a long time and generates a massive amount of data (>100MB). If
403 you want this feature, you must configure LLVM with the --enable-doxygen switch
404 and ensure that a modern version of doxygen (1.3.7 or later) is available in
405 your ``PATH``. You can download doxygen from `here
406 <http://www.stack.nl/~dimitri/doxygen/download.html#latestsrc>`_.
411 This utility target checks to see if the ``Makefile`` in the object directory is
412 older than the ``Makefile`` in the source directory and copies it if so. It also
413 reruns the ``configure`` script if that needs to be done and rebuilds the
414 ``Makefile.config`` file similarly. Users may overload this target to ensure
415 that sanity checks are run *before* any building of targets as all the targets
416 depend on ``preconditions``.
421 This utility target just causes the LLVM makefiles to print out some of the
422 makefile variables so that you can double check how things are set.
427 This utility target will force a reconfigure of LLVM or your project. It simply
428 runs ``$(PROJ_OBJ_ROOT)/config.status --recheck`` to rerun the configuration
429 tests and rebuild the configured files. This isn't generally useful as the
430 makefiles will reconfigure themselves whenever its necessary.
439 This utility target, only available when ``$(PROJ_OBJ_ROOT)`` is not the same as
440 ``$(PROJ_SRC_ROOT)``, will completely clean the ``$(PROJ_OBJ_ROOT)`` directory
441 by removing its content entirely and reconfiguring the directory. This returns
442 the ``$(PROJ_OBJ_ROOT)`` directory to a completely fresh state. All content in
443 the directory except configured files and top-level makefiles will be lost.
448 This target will generate a ``TAGS`` file in the top-level source directory. It
449 is meant for use with emacs, XEmacs, or ViM. The TAGS file provides an index of
450 symbol definitions so that the editor can jump you to the definition
456 This target is the opposite of the ``install`` target. It removes the header,
457 library and executable files from the installation directories. Note that the
458 directories themselves are not removed because it is not guaranteed that LLVM is
459 the only thing installing there (e.g. ``--prefix=/usr``).
466 Variables are used to tell the LLVM Makefile System what to do and to obtain
467 information from it. Variables are also used internally by the LLVM Makefile
468 System. Variable names that contain only the upper case alphabetic letters and
469 underscore are intended for use by the end user. All other variables are
470 internal to the LLVM Makefile System and should not be relied upon nor
471 modified. The sections below describe how to use the LLVM Makefile
477 Variables listed in the table below should be set *before* the inclusion of
478 `$(LEVEL)/Makefile.common`_. These variables provide input to the LLVM make
479 system that tell it what to do for the current directory.
482 If set to any value, causes an archive (.a) library to be built.
485 Specifies a set of source files that are generated from other source
486 files. These sources will be built before any other target processing to
487 ensure they are present.
490 If set to any value, causes a bitcode library (.bc) to be built.
493 Specifies a set of configuration files to be installed.
496 If set to any value, causes the build to include debugging symbols even in
497 optimized objects, libraries and executables. This alters the flags
498 specified to the compilers and linkers. Debugging isn't fun in an optimized
499 build, but it is possible.
502 Specifies a set of directories, usually children of the current directory,
503 that should also be made using the same goal. These directories will be
506 ``DISABLE_AUTO_DEPENDENCIES``
507 If set to any value, causes the makefiles to **not** automatically generate
508 dependencies when running the compiler. Use of this feature is discouraged
509 and it may be removed at a later date.
512 If set to 1, causes the build to generate optimized objects, libraries and
513 executables. This alters the flags specified to the compilers and
514 linkers. Generally debugging won't be a fun experience with an optimized
518 If set to 1, causes the build to generate both optimized and profiled
519 objects, libraries and executables. This alters the flags specified to the
520 compilers and linkers to ensure that profile data can be collected from the
521 tools built. Use the ``gprof`` tool to analyze the output from the profiled
522 tools (``gmon.out``).
524 ``DISABLE_ASSERTIONS``
525 If set to 1, causes the build to disable assertions, even if building a
526 debug or profile build. This will exclude all assertion check code from the
527 build. LLVM will execute faster, but with little help when things go
530 ``EXPERIMENTAL_DIRS``
531 Specify a set of directories that should be built, but if they fail, it
532 should not cause the build to fail. Note that this should only be used
533 temporarily while code is being written.
535 ``EXPORTED_SYMBOL_FILE``
536 Specifies the name of a single file that contains a list of the symbols to
537 be exported by the linker. One symbol per line.
539 ``EXPORTED_SYMBOL_LIST``
540 Specifies a set of symbols to be exported by the linker.
543 Specifies additional files that should be distributed with LLVM. All source
544 files, all built sources, all Makefiles, and most documentation files will
545 be automatically distributed. Use this variable to distribute any files that
546 are not automatically distributed.
549 If set to any value, specifies that when linking executables the makefiles
550 should retain debug symbols in the executable. Normally, symbols are
551 stripped from the executable.
554 Specify the level of nesting from the top level. This variable must be set
555 in each makefile as it is used to find the top level and thus the other
559 Specify the name of the library to be built. (Required For Libraries)
562 When specified for building a tool, the value of this variable will be
563 passed to the ``llvm-config`` tool to generate a link line for the
564 tool. Unlike ``USEDLIBS`` and ``LLVMLIBS``, not all libraries need to be
565 specified. The ``llvm-config`` tool will figure out the library dependencies
566 and add any libraries that are needed. The ``USEDLIBS`` variable can still
567 be used in conjunction with ``LINK_COMPONENTS`` so that additional
568 project-specific libraries can be linked with the LLVM libraries specified
569 by ``LINK_COMPONENTS``.
571 .. _LINK_LIBS_IN_SHARED:
573 ``LINK_LIBS_IN_SHARED``
574 By default, shared library linking will ignore any libraries specified with
575 the `LLVMLIBS`_ or `USEDLIBS`_. This prevents shared libs from including
576 things that will be in the LLVM tool the shared library will be loaded
577 into. However, sometimes it is useful to link certain libraries into your
578 shared library and this option enables that feature.
583 Specifies the set of libraries from the LLVM ``$(ObjDir)`` that will be
584 linked into the tool or library.
587 If set to any value, causes the shared library being built to also be a
588 loadable module. Loadable modules can be opened with the dlopen() function
589 and searched with dlsym (or the operating system's equivalent). Note that
590 setting this variable without also setting ``SHARED_LIBRARY`` will have no
596 Specifies the name of a bitcode module to be created. A bitcode module can
597 be specified in conjunction with other kinds of library builds or by
598 itself. It constructs from the sources a single linked bitcode file.
601 Specifies that the build products of the directory should not be installed
602 but should be built even if the ``install`` target is given. This is handy
603 for directories that build libraries or tools that are only used as part of
604 the build process, such as code generators (e.g. ``tblgen``).
607 Specify a set of directories that may be built, if they exist, but it is
608 not an error for them not to exist.
611 Specify a set of directories to build recursively and in parallel if the
612 ``-j`` option was used with ``make``.
617 If set to any value, causes a shared library (``.so``) to be built in
618 addition to any other kinds of libraries. Note that this option will cause
619 all source files to be built twice: once with options for position
620 independent code and once without. Use it only where you really need a
623 ``SOURCES`` (optional)
624 Specifies the list of source files in the current directory to be
625 built. Source files of any type may be specified (programs, documentation,
626 config files, etc.). If not specified, the makefile system will infer the
627 set of source files from the files present in the current directory.
630 Specifies a set of filename suffixes that occur in suffix match rules. Only
631 set this if your local ``Makefile`` specifies additional suffix match
635 Specifies the name of the LLVM code generation target that the current
636 directory builds. Setting this variable enables additional rules to build
637 ``.inc`` files from ``.td`` files.
642 Specifies the directory of tests to run in ``llvm/test``.
645 Specifies the name of the tool that the current directory should build.
648 Implies ``VERBOSE`` and also tells each tool invoked to be verbose. This is
649 handy when you're trying to see the sub-tools invoked by each tool invoked
650 by the makefile. For example, this will pass ``-v`` to the GCC compilers
651 which causes it to print out the command lines it uses to invoke sub-tools
652 (compiler, assembler, linker).
657 Specifies the list of project libraries that will be linked into the tool or
661 Tells the Makefile system to produce detailed output of what it is doing
662 instead of just summary comments. This will generate a LOT of output.
667 Override variables can be used to override the default values provided by the
668 LLVM makefile system. These variables can be set in several ways:
670 * In the environment (e.g. setenv, export) --- not recommended.
671 * On the ``make`` command line --- recommended.
672 * On the ``configure`` command line.
673 * In the Makefile (only *after* the inclusion of `$(LEVEL)/Makefile.common`_).
675 The override variables are given below:
678 Specifies the path to the ``ar`` tool.
681 The directory into which the products of build rules will be placed. This
682 might be the same as `PROJ_SRC_DIR`_ but typically is not.
687 The directory which contains the source files to be built.
690 If set to 1, build examples in ``examples`` and (if building Clang)
691 ``tools/clang/examples`` directories.
693 ``BZIP2`` (configured)
694 The path to the ``bzip2`` tool.
697 The path to the 'C' compiler.
700 Additional flags to be passed to the 'C' compiler.
703 Additional flags passed to the C/C++ preprocessor.
706 Specifies the path to the C++ compiler.
709 Additional flags to be passed to the C++ compiler.
711 ``DATE`` (configured)
712 Specifies the path to the ``date`` program or any program that can generate
713 the current date and time on its standard output.
716 Specifies the path to the ``dot`` tool or ``false`` if there isn't one.
718 ``ECHO`` (configured)
719 Specifies the path to the ``echo`` tool for printing output.
721 ``EXEEXT`` (configured)
722 Provides the extension to be used on executables built by the makefiles.
723 The value may be empty on platforms that do not use file extensions for
724 executables (e.g. Unix).
726 ``INSTALL`` (configured)
727 Specifies the path to the ``install`` tool.
729 ``LDFLAGS`` (configured)
730 Allows users to specify additional flags to pass to the linker.
732 ``LIBS`` (configured)
733 The list of libraries that should be linked with each tool.
735 ``LIBTOOL`` (configured)
736 Specifies the path to the ``libtool`` tool. This tool is renamed ``mklib``
737 by the ``configure`` script.
739 ``LLVMAS`` (defaulted)
740 Specifies the path to the ``llvm-as`` tool.
743 Specifies the path to the LLVM capable compiler.
746 Specifies the path to the LLVM C++ capable compiler.
748 ``LLVMGCC`` (defaulted)
749 Specifies the path to the LLVM version of the GCC 'C' Compiler.
751 ``LLVMGXX`` (defaulted)
752 Specifies the path to the LLVM version of the GCC C++ Compiler.
754 ``LLVMLD`` (defaulted)
755 Specifies the path to the LLVM bitcode linker tool
757 ``LLVM_OBJ_ROOT`` (configured)
758 Specifies the top directory into which the output of the build is placed.
760 ``LLVM_SRC_ROOT`` (configured)
761 Specifies the top directory in which the sources are found.
763 ``LLVM_TARBALL_NAME`` (configured)
764 Specifies the name of the distribution tarball to create. This is configured
765 from the name of the project and its version number.
767 ``MKDIR`` (defaulted)
768 Specifies the path to the ``mkdir`` tool that creates directories.
771 If set, specifies the list of tools to build.
773 ``PLATFORMSTRIPOPTS``
774 The options to provide to the linker to specify that a stripped (no symbols)
775 executable should be built.
777 ``RANLIB`` (defaulted)
778 Specifies the path to the ``ranlib`` tool.
781 Specifies the path to the ``rm`` tool.
784 Specifies the path to the ``sed`` tool.
786 ``SHLIBEXT`` (configured)
787 Provides the filename extension to use for shared libraries.
789 ``TBLGEN`` (defaulted)
790 Specifies the path to the ``tblgen`` tool.
793 Specifies the path to the ``tar`` tool.
796 Specifies the path to the ``zip`` tool.
801 Variables listed in the table below can be used by the user's Makefile but
802 should not be changed. Changing the value will generally cause the build to go
803 wrong, so don't do it.
806 The directory into which executables will ultimately be installed. This
807 value is derived from the ``--prefix`` option given to ``configure``.
810 The name of the type of build being performed: Debug, Release, or
814 The directory into which bitcode libraries will ultimately be installed.
815 This value is derived from the ``--prefix`` option given to ``configure``.
817 ``ConfigureScriptFLAGS``
818 Additional flags given to the ``configure`` script when reconfiguring.
821 The *current* directory for which a distribution copy is being made.
826 The LLVM Makefile System output command. This provides the ``llvm[n]``
827 prefix and starts with ``@`` so the command itself is not printed by
831 Same as `Echo`_ but without the leading ``@``.
834 The directory into which include files will ultimately be installed. This
835 value is derived from the ``--prefix`` option given to ``configure``.
838 The directory into which native libraries will ultimately be installed.
839 This value is derived from the ``--prefix`` option given to
843 The configuration specific directory into which libraries are placed before
847 Full path of the ``Makefile.config`` file.
850 Full path of the ``Makefile.config.in`` file.
853 The configuration and directory specific directory where build objects
854 (compilation results) are placed.
857 The complete list of sub-directories of the current directory as
858 specified by other variables.
861 The complete list of source files.
864 The directory into which configuration files will ultimately be
865 installed. This value is derived from the ``--prefix`` option given to
869 The configuration specific directory into which executables are placed
870 before they are installed.
873 The top most directory into which the distribution files are copied.
876 Use this as the first thing on your build script lines to enable or disable
877 verbose mode. It expands to either an ``@`` (quiet mode) or nothing (verbose
883 Variables listed below are used by the LLVM Makefile System and considered
884 internal. You should not use these variables under any circumstances.
886 .. code-block:: makefile