Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
XMAKE(1)		    General Commands Manual		      XMAKE(1)

       xmake - portable	make utility

       xmake [ -v ] [ -f xmakefile ] [ -d[#] ] [ -n ] [	-D sym[=data] ]	label1
       ... labelN

       -v	  print	version	and exit.  If xmake doesn't know what  version
       it is, someone forgot to	re-make	and re-install it with itself.

       -f	  specify different default file

       -d[#]	  turn on debugging

       -n	  dry run - do not execute commands lists

       -Dsym[=data]	specify	additional symbols to call cpp with, also sets
       the EXTDEFS variable

       XMake is	a make utility.	 It is not compatible with  other  makes,  but
       provides	extended functionality over most standard makes.  Whereas most
       other makes have	confusing rulesets and do not support many-to-many de-
       pendancy	 specifications, XMake has relatively few (basically no) rule-
       sets and	allows you to easily  specify  many:many  dependancies.	  This
       gives  XMake  the  flexibility to deal with complex project hierarchies
       very simply.  Despite the fact that there are no	built-in rulesets,  an
       XMakefile  is  often no more complex then a normal Makefile.  XMake in-
       corporates the following	major features:

       The ability to specify one-to-many, and many-to-one dependancies

       The ability to apply a single command list to many one-to-one dependan-
       cies  (typically	lots of	object files depending on lots of source files
       can be dealt with in a single line).

       The ability to embed shell commands (e.g.  find,	 ls,  whatever...)  in
       variable	and other definitions.

       The  ability to generate	wildcard template conversions on the fly.  For
       example,	you can	list the source	files and generate  the	 object	 files
       and all associated dependancies from the	source file list.

       Runs  the  C preprocessor, allowing you to use #if/#else/#endif and, if
       need be,	use preprocessor macros.  The main purpose is to  support  the
       #include	directive and allow operating system and compiler auto-detect.

       Maintains special 'dependancy' variables	%(left)	and %(right) which may
       used in command sequences.

       Allows variables	to be .set inside a command sequence, where  the  .set
       directive  is executed when/if the command sequence is executed... use-
       ful when	dealing	with side effect issues.

       Understands delayed-expansion variable specifications.  A normal	 vari-
       able  specification is something	like $(NAME) or	%(NAME), whereas a de-
       layed-expansion variable	specification is something like	${NAME}.  This
       allows  you to set up global variables whos contents are	based on other
       variables which have not	yet been initialized.  The variable  is	 fully
       resolved	 when  used  in	 a dependancy or executed as part of a command

       By default, XMake attempts to access the	XMakefile in the  current  di-
       rectory.	 This can be overriden with the	-f option.

       Directives must start in	column 1.  XMake understands the following di-

       .set varname contents

       Set the contents	of the specified variable

       .beg / .end

       Applicable only within a	command	sequence, allows blank lines to	be in-
       serted without terminating a command sequence.

       Variables may be	referenced in any one of several ways:


       The  $()	 variable form references a .set variable, while the %() vari-
       able form references a special dependancy variable.   Dependancy	 vari-
       ables  only  work  within  command  sequences.	Currently  %(left) and
       %(right)	are defined.  %(left) represents the left hand side of the de-
       pendancy, while %(right)	represents the right hand side.

       The  optional  wildmatch	 and wildreplace elements allow	you to dynami-
       cally restrict transform	the elements contained	within	the  variable.
       For  example,  if a variable contains a mix of .c and .h	files, you can
       extract just the	.c files with $(VARNAME:*.c)  .	  Transformations  are
       accomplished  with a third element.  Each '*' or	'?'  in	the match side
       is represented by %1 to %N on the replace side.	You can	also  use  '*'
       and  '?'	 on  the replace side, which sequentially represent %1 ... %N.
       The most	common transformation is something like	this:

	.set SRCS	include.c list.c main.c	subs.c
	.set OBJS	$(SRCS:"*.c":"$(OD)/*.o")

       XMake allows you	to specify dependancies	in a manner simliar  to	 make.
       However,	 XMake extends the facility to allow many one-to-one dependan-
       cies to be specified on a single	line, as well as  other	 combinations.
       The format for a	dependancy is:

       d1 d2 ... dn : s1 s2 ...	sn [ : a1 a2 a3	... aX ]
       d1 : s1 s2 ... sn [ : a1	a2 a3 ... aX ]
       d1 d2 ..	dn : [ : s1 a2 a3 ... aX ]

       In the first form, each dN is dependant on the associated sN and	ALL of
       the a1-aX elemnts.

       In the second form, a single d1 depends on ALL of the s1-sN  and	 a1-aX

       In the third form, each destination dN depends on ALL of	the a1-aX ele-
       ments, and there	are no 's' elements listed at all.

       Note that the a1..aX elements are optional.  You	may also specify a de-
       pendancy	 with no right hand side elements at all.  This	will cause the
       execution list for the left hand	side to	be run if the left  hand  side
       is ever depended	upon from a higher level.

       The right hand side is not required to represent	a real file if its la-
       bel is used on the left hand side of another dependancy.	  However,  if
       it  does	represent a real file, then the	'return	code' will be based on
       a time-stamp comparison even if the sub-dependancies of the right  hand
       side  themselves	 are  out of date and cause commands to	run.  The best
       example of this is the PROTOS dependancy	shown below:

       $(OBJS):: $(PROTOS)

       $(OBJS):: defs.h

       $(OBJS):	$(SRCS)
	   cc $(CFLAGS)	%(right) -o %(left) -c

       $(PROTOS): $(OD)/$(XMKPROTO) $(SRCS)
	   $(OD)/$(XMKPROTO) -o	%(left)	%(right:"*.c")

       In this example,	the object modules are dependant on the	prototype file
       being  up-to-date  (as well as defs.h).	However, the prototype file is
       updated by xmkproto if any of the source	 files	change.	  xmkproto  is
       smart enough to not touch the prototype file if it determines that none
       of the prototypes have changed.	Even though the	PROTOS:SRCS dependancy
       is  run,	 the  OBJS:PROTOS dependancy will not be run if	the prototypes
       file was	not actually modified.

       XMake automatically includes the	following directories when it runs CPP
       on your XMakefile:
       The . directory
       The .. directory
       Your $HOME/.xmk directory

       This allows you to configure XMake in a global system, with local over-
       rides.  Most XMakefiles will not	need any of  these  directories.   The
       most useful is the . and	.. directories,	which allow you	to setup hier-
       archical files which are recursively included.

       It is extremely easy to construct XMakefile's that use a	single file or
       directory list to compile an entire project.  Once you have learned how
       to use the wildcard match-and-replace capabilities, you will wonder how
       you  could  have	 lived	without	it before.  Amoung other things, these
       functions allow you to mix multiple file	extensions in a	 single	 vari-
       able, such as SRCS, yet apply a different ruleset to each extension.

       XMakefile      default xmake control file
       $HOME/.xmk	   In include path for cpp
       /usr/local/share/xmk	In include path	for cpp
       /usr/share/xmk	   In include path for cpp



Want to link to this manual page? Use this URL:

home | help