X-Git-Url: http://demsky.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FMakefileGuide.html;h=7b4b7552c1dee99631c636d30817a6fc0842fb7f;hb=35b9a7790e904abce4e6dac3f1ed89696522f19a;hp=b1398bb8b17e487e84dafef024a4aeebf1416461;hpb=d1001f2ac20d5f83037fa418769a8622b3413305;p=oota-llvm.git diff --git a/docs/MakefileGuide.html b/docs/MakefileGuide.html index b1398bb8b17..7b4b7552c1d 100644 --- a/docs/MakefileGuide.html +++ b/docs/MakefileGuide.html @@ -30,7 +30,7 @@
In some situations, it is desireable to build a single bytecode module from - a variety of sources, instead of an archive, shared library, or bytecode - library. Bytecode modules can be specified in addition to any of the other +
In some situations, it is desireable 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:
@@ -273,9 +273,9 @@ 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 bytecode modules - derived from the sources. The example will also build a bytecode archive - containing a bytecode module for each compiled source file. The difference is + 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.
LIBRARYNAME := MyMod LOADABLE_MODULE := 1 - USEDLIBS := LLVMSupport.a LLVMSystem.a + LINK_COMPONENTS := support system
Use of the LOADABLE_MODULE facility implies several things:
TOOLNAME = mytool USEDLIBS = mylib - LLVMLIBS = LLVMSupport.a LLVMSystem.a + LINK_COMPONENTS = support system
says that we are to build a tool name mytool and that it requires three libraries: mylib, LLVMSupport.a and @@ -352,36 +352,22 @@
Many tools will want to use the JIT features of LLVM. However, getting the - right set of libraries to link with is tedious, platform specific, and error - prone. Additionally, the JIT has special linker switch options that it needs. - Consequently, to make it easier to build tools that use the JIT, you can - use a special value for the LLVMLIBS variable:
+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:
TOOLNAME = my_jit_tool USEDLIBS = mylib - LLVMLIBS = JIT + LINK_COMPONENTS = engine-
Using a value of JIT for LLVMLIBS tells the makefile - system to construct a special value for LLVMLIBS that gives the program all - the LLVM libraries needed to run the JIT. Any additional libraries needed can - still be specified with USEDLIBS. To get a full understanding of how - this changes the linker command, it is recommended that you:
+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:
cd examples/Fibonacci make VERBOSE=1-
By default, using LLVMLIBS=JIT will link in enough to support JIT - code generation for the architecture on which the tool is linked. If you need - additional target architectures linked in, you may specify them on the command - line or in your Makefile. For example:
-- ENABLE_X86_JIT=1 - ENABLE_SPARCV9_JIT=1 - ENALBE_PPC_JIT=1 --
will cause the tool to be able to generate code for all three platforms. -