jamfile.html

jam源码

<P>
<P>
<H4>
   SubInclude Rule
</H4>
	The SubInclude rule is used in a Jamfile to cause another
	Jamfile to be read in.
       Its arguments are in  the  same  format  as
       SubDir's.
<P>
       The  recommended  practice is only to include one level of
       subdirectories at a time, and let the Jamfile in each subdirectory  
       include  its own subdirectories.  This allows a
       user to sit in any arbitrary directory of the source  tree
       and build that subtree.  For example:
<PRE>
       # This is $(TOP)/Jamfile, top level Jamfile for mondo project.

       SubInclude TOP src ;
       SubInclude TOP man ;
       SubInclude TOP misc ;
       SubInclude TOP util ;
</PRE>
       If  a directory has both subdirectories of its own as well
       as files that need building,  the  SubIncludes  should  be
       either before the SubDir rule or be at the end of the Jamfile 
       - not between the SubDir and other rule  invocations.
       For example:
<PRE>
	# This is $(TOP)/src/Jamfile:

	SubDir TOP src ;

	Main mondo : mondo.c ;
	LinkLibraries mondo : libmisc libutil ;
	
	SubInclude TOP src misc ;
	SubInclude TOP src util ;
</PRE>
<P>
	(<b>jam</b> processes all the Jamfiles it reads as if
	it were reading one single, large Jamfile. 
	Build rules like Main and LinkLibraries rely on the
	preceding SubDir rule to set up source file and
	output file locations, and SubIncludes rules read in
	Jamfiles that contain SubDir rules. So if you put
	a SubIncludes rule between a SubDir and a Main
	rule, <b>jam</b> will try to find the source files
	for the Main rule in the wrong directory.)
<P>
<H4>
   Variables Used to Handle Directory Trees
</H4>
       The  following  variables are set by the SubDir rule
       and used by the Jambase rules that define file targets:
<P>
<CENTER>
<TABLE>
<TR><TD VALIGN=TOP>
              SEARCH_SOURCE
	      <TD><TD>The SubDir targets (e.g., "TOP src util")
	      are used to construct a pathname (e.g., $(TOP)/src/util),
	      and that pathname is assigned to $(SEARCH_SOURCE). 
	      Rules like Main and Library use $(SEARCH_SOURCE)
	      to set search paths on source files.
<TR><TD VALIGN=TOP>
              LOCATE_SOURCE
	      <TD><TD>Initialized by the SubDir rule to the same
	      value as $(SEARCH_SOURCE), unless ALL_LOCATE_TARGET
	      is set.
	      $(LOCATE_SOURCE) is used by rules that build
	      generated source files (e.g., Yacc and Lex) to
	      set location of output files.
	      Thus the default location of built source files
	      is the directory of the Jamfile that defines them.
<TR><TD VALIGN=TOP>
              LOCATE_TARGET
	      <TD><TD>Initalized by the SubDir rule to the same
	      value as $(SEARCH_SOURCE), unless ALL_LOCATE_TARGET
	      is set.
	      $(LOCATE_TARGET) is used by rules that build
	      binary objects (e.g., Main and Library) to
	      set location of output files.
	      Thus the default location of built binaray files
	      is the directory of the Jamfile that defines them.
<TR><TD VALIGN=TOP>
              ALL_LOCATE_TARGET
	      <TD><TD>
	      If $(ALL_LOCATE_TARGET) is set, LOCATE_SOURCE
	      and and LOCATE_TARGET are set to  $(ALL_LOCATE_TARGET)
	      instead of to $(SEARCH_SOURCE). This can be used to
	      direct built files to be written to a location outside
	      of the source tree, and enables building from read-only
	      source trees.
<TR><TD VALIGN=TOP>
              SOURCE_GRIST
	      <TD><TD>The SubDir targets are formed into a string
	      like "src!util" and that string is assigned to 
	      SOURCE_GRIST. Rules that define file targets
	      use $(SOURCE_GRIST) to set the "grist" attribute
	      on targets. This is used to assure uniqueness 
	      of target identifiers where filenames themselves
	      are not unique.
	      For example, the target identifiers of 
	      $(TOP)/src/client/main.c and $(TOP)/src/server/main.c
	      would be &lt;src!client&gt;main.c and &lt;src!server&gt;main.c.
</TABLE>
</CENTER>
<P>
       The $(LOCATE_TARGET) and  $(SEARCH_SOURCE)  variables are used
       extensively by rules in Jambase: most rules that  generate
       targets  (like  Main,  Object,  etc.)  set $(LOCATE) to 
       $(LOCATE_TARGET) for the targets they generate, and  rules
       that  use  sources  (most all of them) set $(SEARCH) to be
       $(SEARCH_SOURCE) for the sources they use.
<P>
       $(LOCATE) and $(SEARCH) are better  explained  in  
       <A HREF="Jam.html">The Jam Executable Program</A>
       but in brief they tell <B>jam</B> where to create new targets and
       where to find existing ones, respectively.
<P>
       Note that you can reset these variables
       after SubDir sets them. For example, this Jamfile builds
       a program called gensrc, then runs it to create a source file
       called new.c: 
       <PRE>
       SubDir TOP src util ;
       Main gensrc : gensrc.c ;
       LOCATE_SOURCE = $(NEWSRC) ;
       GenFile new.c : gensrc ;
       </PRE>
       By default, new.c would be written into the
       $(TOP)/src/util directory, but resetting LOCATE_SOURCE causes
       it to be written to the $(NEWSRC) directory. ($(NEWSRC) is assumed
       to have been set elsewhere, e.g., in Jamrules.)
<P>
<H4>
   VMS Notes
</H4>
       On VMS, the logical name table is not imported as  is  the
       environment on UNIX.  To use the SubDir and related rules,
       you must set the value of the variable that names the root
       directory.  For example:
<PRE>
              TOP = USR_DISK:[JONES.SRC] ;

              SubInclude TOP util ;
</PRE>
       The variable must have a value that looks like a directory
       or device.  If you choose, you can use a  concealed  logical.  
       For example:
<PRE>
              TOP = TOP: ;

              SubInclude TOP util ;
</PRE>
       The  :  at  the  end of TOP makes the value of $(TOP) look
       like a device name, which jam respects as a directory name
       and  will  use when trying to access files.  TOP must then
       be defined from DCL:
<PRE>
              $ define/job/translation=concealed TOP DK100:[USERS.JONES.SRC.]
</PRE>
       Note three things: the concealed  translation  allows  the
       logical  to  be  used as a device name; the device name in
       the logical (here DK100) cannot itself be concealed  logical  
       (VMS  rules, man); and the directory component of the
       definition must end in a period (more VMS rules).
<P>
<H2>
Building Executables and Libraries
</H2>
<P>
The rules that build executables and libraries are: Main, Library,
and LinkLibraries.
<H4>
   Main Rule
</H4>
       The Main rule compiles source files and links the  resulting 
       objects into an executable.  For example:
<PRE>
              Main myprog : main.c util.c ;
</PRE>
       This  compiles  main.c  and  util.c  and  links main.o and
       util.o into myprog. The object files and resulting 
       executable are named appropriately for the platform.
<P>
	Main can also be used to build shared libraries and/or
	dynamic link libraries, since those are also linked
	objects. E.g.:
	<PRE>
		Main driver$(SUFSHR) : driver.c ;
	</PRE>
	Normally, Main uses $(SUFEXE) to determine the suffix on
	the filename of the built target. To override it,
	you can supply a suffix explicity.
	In this case,
	$(SUFSHR) is assumed to be the OS-specific shared library
	suffix, defined in Jamrules with something
	like:
	<PRE>
		if $(UNIX)      { SUFSHR = .so ; }
		else if $(NT)   { SUFSHR = .dll ; }
	</PRE>
	<P>
	Main uses the Objects rule to compile source targets. 

<H4>
   Library Rule
</H4>
       The Library  rule  compiles  source  files,  archives  the
       resulting  object  files  into a library, and then deletes
       the object files.  For example:
<PRE>
              Library libstring : strcmp.c strcpy.c strlen.c ;
              Library libtree : treemake.c treetrav.c ;
</PRE>
       This compiles five source files,  archives  three  of  the
       object  files into libstring and the other two into libtree.  
       Actual library filenames are formed with the $(SUFLIB) suffix.
       Once the objects are safely in the libraries, the
       objects are deleted.
       <P>
       Library uses the Objects rule to compile source files.
<P>
<H4>
   LinkLibraries Rule
</H4>
       To link executables with built libraries, use
       the LinkLibraries rule.  For example:
<PRE>
              Main myprog : main.c util.c ;
              LinkLibraries myprog : libstring libtree ;
</PRE>
       The LinkLibraries rule  does  two  things:  it  makes  the
       libraries dependencies of the executable, so that they get
       built first; and it makes the libraries  show  up  on  the
       command  line  that links the executable.  The ordering of
       the lines above is not important, because <b>jam</b> builds  targets 
       in the order that they are needed.
<P>
       You  can  put multiple libraries on a single invocation of
       the LinkLibraries rule, or you can provide them in  multiple  
       invocations.   In both cases, the libraries appear on
       the link command line in the  order  in  which  they  were
       encountered.  You can also provide multiple executables to
       the LinkLibraries rule, if they need the same libraries,
       e.g.:
       <PRE>
		LinkLibraries prog1 prog2 prog3 : libstring libtree ;
       </PRE>
<P>
<H4>
   Variables Used in Building Executables and Libraries
</H4>
<CENTER>
<TABLE>
<TR><TD>
              AR           
	      <TD><TD>Archive command, used for Library targets.
<TR><TD>
              SUFEXE         
	      <TD>*<TD>Suffix on filenames of executables referenced
		by Main and LinkLibraries.
<TR><TD>
              LINK           
	      <TD><TD>Link command, used for Main targets.
<TR><TD>
              LINKFLAGS       
	      <TD><TD>Linker flags.
<TR><TD>
              LINKLIBS        
	      <TD><TD>Link libraries that aren't dependencies. (See note
		below.)
<TR><TD>
              EXEMODE         
	      <TD>*<TD>File permissions on Main targets.
<TR><TD>
              MODE            
	      <TD><TD>Target-specific file permissions on Main targets
		(set from $(EXEMODE))
<TR><TD>
              RANLIB          
	      <TD><TD>Name of ranlib program, if any.
</TABLE>
</CENTER>

<P>
	Variables above marked with "*" are used by the Main,
	Library, and LinkLibraries rules. Their values at the 
	time the rules are invoked are used to set target-specific
	variables.
	<P>
	All other variables listed above are globally defined,
	and are used in actions that update Main and Library
	targets. This means that the global values of those
	variables are used, uness target-specific values have
	been set. 
	(For instance, a target-specific MODE value is set by 
	the Main rule.)
	The target-specific values always override
	global values.
<P>
	Note that there are two ways to specify link libraries for
	executables: 
	<UL>
	<LI>Use the LinkLibraries rule 
	to specify built libraries; i.e., libraries
	that are built by Library rules. This assures that
	these libraries are built first, and that Main targets are 
	rebuilt when the libraries are updated.
	<P>
	<LI>Use the LINKLIBS variable to specify external
	 libraries; e.g., system libraries or third-party libraries.
	 The LINKLIBS variable must be set to the the actual
	 link command flag that specifies the libraries.
	 <P>
	 </UL>
	 <P>
	 For example:
<PRE>
	<I>#In Jamrules:</I>
              if $(UNIX) { X11LINKLIBS = -lXext -lX11 ; }
              if $(NT)   { X11LINKLIBS = libext.lib libX11.lib ; }

	<I>#In Jamfile:</I>
              Main xprog : xprog.c ;
              LINKLIBS on xprog$(SUFEXE) = $(X11LINKLIBS) ;
              LinkLibraries xprog : libxutil ;
              Library libxutil : xtop.c xbottom.c xutil.c ;
</PRE>
       This  example  uses the Jam syntax "variable on target" to
       set a target-specific variable.  In this way,  only  xprog
       will  be linked with this special $(X11LINKLIBS), 
       even if other executables were going to  be  built
       by  the  same Jamfile. Note that when you set a variable
       on a target, you have to specify the target identifer
       exactly, which in this case is the suffixed filename of
       the executable.
       The actual link command line on Unix, for example, would
       look something like this:
<PRE>
              cc -o xprog xprog.o libxutil.a -lXext -lX11
</PRE>
<H2>
Compiling
</H2>
       Compiling of source files occurs normally as  a  byproduct
       of  the Main or Library rules, which call the rules 
       described here. These rules may also be called explicitly
       if the Main and Library behavior doesn't satisfy your
       requirements.
<P>
<H4>
   Objects Rule
</H4>
       The Main and Library rules call the Objects rule on source files.
       Compiled object files built by
       the Objects rule are a dependency of the <I>obj</i>
       pseudotarget, so "jam obj" will build object files used in 
       Main and Library rules.
       <P>
       Target identifiers created by the Objects rule have grist